Leaderboard

Of course ! I'm just going to underlay a serious problem. In the past, no one bothered himself to understand optimization (even great developer/company didn't) because CPUs were evolving so fast and each new generation beats the previous one by a large margin(people were just upgrading their CPUs and seeing performance x2,x3). But today we are reaching a dead point (Moore's Law) and the difference between a new generation and the previous isn't really significant ! So today the effort is jumping from CPUs to compilers/parallel programming. In the past few years, we have seeing the emergence of LLVM as a powerful compiler infrastructure and big whales started to communicate with each other more than ever. In a nutshell, tomorrow problem is optimization. The way how many choose to deal with it, is improving compiler. And I really think that Delphi should join this race ASAP.

Yeah, that seems like a god idea.

Why can't we have both - a fast compilation generating debug friendly non optimized code and one that churns a little longer and emits those juicy optimizations. Anyhow the current slowliness in the compiler comes from sloppy code in the compiler and not because it does so many amazing things.

Thanks very much for creating a space here for C++Builder users. There is not a lot of community support out there for C++Builder (and none from Embarcadero anymore - what a shame). It looks like the Delphi-PRAXiS forum is well used which is great. Even though I don't use Delphi I still learn about VCL and other topics from the Delphi crowd. Glad to see that it is active.

@Stefan Glienke SIMD are very powerful but they come with their issues too(portability, alignment for some instructions,... ). Some compilers have a great stuff to embarrasse those issues. But neither delphi compiler nor the RTL helps (we don't even have AVX) 😥 I really wish if at some point of time Delphi supports SIMD through intrinsics or some vector types.

@Arnaud Bouchez This report is 10 years old. Things have changed, drivers are OK now, DirectX and Direct2D have changed.

Partially SIMDed without trailing ... and it beat all 🙂 const { Source Data Format : Imm8[1:0] } DF_UNSIGNED_BYTES = 0; DF_UNSIGNED_WORDS = 1; DF_SIGNED_BYTES = 2; DF_SIGNED_WORDS = 3; { Aggregation Operation : Imm8[3:2] } AGGREGATION_OP_EQUAL_ANY = 0 shl 2; AGGREGATION_OP_RANGES = 1 shl 2; AGGREGATION_OP_EQUAL_EACH = 2 shl 2; AGGREGATION_OP_EQUAL_ORDERED = 3 shl 2; { Polarity : Imm8[5:4] } POLARITY_POSITIVE = 0 shl 4; POLARITY_NEGATIVE = 1 shl 4; POLARITY_MASKED_POSITIVE = 2 shl 4; POLARITY_MASKED_NEGATIVE = 3 shl 4; { Output Selection : Imm8[6] } OS_LSI = 0 shl 6; OS_MSI = 1 shl 6; OS_BIT_MASK = 0 shl 6; OS_BYTE_WORD_MASK = 1 shl 6; const [Align(16)] Range: array [0 .. 7] of Char = '09afAF' + #00; function IsValidHex(P: Pointer): Boolean; asm movdqa xmm1, [Range] sub eax, 16 @@SimdLoop: add eax, 16 movdqu xmm2, [eax] pcmpistri xmm1, xmm2, DF_UNSIGNED_WORDS or AGGREGATION_OP_RANGES or POLARITY_NEGATIVE ja @@SimdLoop test Word [eax + ecx *2], -1 setz al end; function HexToBinMahdiOneShot(const HexValue: string): string; type TChar4 = array [0 .. 3] of Char; PChar4 = ^TChar4; const Table: array [0 .. 25] of TChar4 = ('0000', '1010', '1011', '1100', '1101', '1110', '1111', '0000', '0000', '0000', '0000', '0000', '0000', '0000', '0000', '0000', '0000', '0001', '0010', '0011', '0100', '0101', '0110', '0111', '1000', '1001'); var P: PChar4; I, Len: Integer; begin SetLength(Result, Length(HexValue) * 4); P := PChar4(Result); if IsValidHex(Pointer(HexValue)) then begin Len := Length(HexValue); for I := 1 to Len do begin P^ := Table[Ord(HexValue[I]) and 31]; Inc(P); end; end else raise EConvertError.CreateFmt('Invalid hex : %s', [HexValue]); end;

Well that is the optimizations that some people were aware of and some weren't - why would that be unfair? P.S. What did I win? Joking aside - it's always interesting that different people see different things. And at the same time it's very sad that perfectly fine code will be like 3-4 times slower than hardcore optimized code simply because the compiler does not know about some things, does not do zero cost abstractions (*) and does not reorder code to make it better. (*) I mean seriously - why do an LStrAsg on a string parameter - as if that would go invalid in the middle of the loop or what?! And because you cannot assign to a loop variable it should treat it exactly the same way as a moving PChar over the string.

That sounds more like use case for code templates. A bit more work to set up, but it would save a lot of typing later on.

Refactor it into a generic unit. Save it in its own Git repository (or have all these utility units in a single repository). Reuse it as a Git submodule in the projects where I need it. Git submodules are a bit of a hassle but it's better than just copying units into other projects and then have to manually update each one every time you fix a bug or make an enhancement.

Kids these days - making them 64bit would be the lazy solution - being more reasonable with allocating memory would be the good one. Especially with confirmed performance issues in the compiler that are caused by unnecessary heap allocations.

Please don't misuse "tag" for pointers. I'd rather use a tDictionary<tcomponent, tSomethingelse> to store associations between components and objects. It's much more universal and transparent.