Stefan Glienke

PSA: Looks like that integer division is broken in 12 due to implementing this feature request. There are at least two reports already about this: https://quality.embarcadero.com/browse/RSP-43274 https://quality.embarcadero.com/browse/RSP-43418 Personally, I would say this absolute "need a hotfix asap" severity. I am honestly really sad about this because this encourages everyone who shies away from requesting any improvements to the compiler because it is almost certain that s**t will fall apart after. 😒

What you actually want to say is that the register allocator is bad (and that also applies to Win64) - which I agree with and has been reported repeatedly. However, pointing out one of the thousands of different specific cases is not getting us anywhere. Especially since there are way more impactful situations where this causes excessive stack spilling.

That code only wastes 2 bytes of binary code because the CPU will most likely apply register renaming and mov elimination (yes, there is some cost for decoding the unnecessary mov). But from all the possible optimizations in the x86 and x86-64 codegen this is one of the least important ones I can think of. FWIW x86-64 code will emit the lea instruction for both.

What? NativeInt is basically Int64 on a 64-bit target platform.

I do, but I know a dozen other things I would rather like to have, and know most of them have been reported for almost a decade or longer and nothing has happened about them - such as this no-brainer.

It's cute that you only have x86 in mind when discussing this.

Could a goto out of a try block be supported - yes. It would require properly transferring control to the finally blocks and then transferring control to the target label. This would require significant work in the compiler. Given how popular the use of goto is, that would be a complete waste of resources. See how the C# spec defines the behavior of a goto out of a try block: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/statements#13104-the-goto-statement

More features, better performance, fewer bugs (and if there are any not having to wait for the Delphi version that fixes them), less binary code bloat.

At least in 13 they would have an excuse for poor quality

Also not true (anymore, it might have been decades ago) - or it might happen that a shifting pointer might be better because of register pressure or shortage under x86 because it only requires one register opposed to two when indexing into an array. But indexing into a memory address with an increasing or decreasing index register is always faster. Another situation might happen when your array is a field of your class and you index into that one because then the compiler is really stupid and re-reads the field every time and then indexes into it. But then the issue is re-reading the field and not the indexing into it. I solved this by putting the array into a local pointer variable and then index into that one - like here. And yet another situation happens on 64bit when using an Integer index variable because then it always does an extra register widening instruction which can be not zero cost (yes, I need to fix the code I just pointed to because it does exactly that having i declared as Integer and not NativeInt as it should be, shoot me). Oh, one particular bad thing about dcc64 is that it does not really optimize some instructions in loops well. From dcc32 we know about the counting down to 0 behavior of a for-to loop where it maintains two counters, the actual index variable (if you actually use that within the loop) and the counting down to 0 variable that it uses to control the loop. For that it usually uses the dec/jnz combination which works well, macro fuses and all that. On win64 it does sub reg, 1, test reg, reg, jnz where only test and jnz fuse which causes wasted cycles. That extra test is complete bonkers because the sub (which should actually be a dec) already sets the zero flag! See RSP-37745 Another missed opportunity of loop optimization that affects both win32 and win64 is letting the compiler create loop that counts from -count to -1 which is another optimization technique where you grab the position after the last element then index into it. This way if you don't need the index variable itself for something else than indexing you only need 2 registers, one points to right after the last element and the loop just needs the nicely fusing inc reg, jnz

This is false knowledge - it only does repeated calls to Length when you do for x in some_dynamic_array do loop

If you care about such things you are totally wrong using Delphi - especially 64bit. It does suboptimal use of all the registers available in 64bit, it produces a crapton of conditional jumps instead of better alternatives that exist for decades, it does not use SSE (let alone AVX) which exists almost as long (except for some floating point stuff), it does zero optimization wrt to loop alignment, it does not restructure binary code so that some cold code does not sit in the middle of some hot code. I could go on, but these are just a few things that matter more if you really care about the least ns squeezed out of your application than some 300K of binary size.

It better be - I spent quite some time on it. FWIW it was already introduced in 11.3

You realize that it's not "exact same code" if you compare 11 and 12, right? The code in the RTL and the VCL or FMX (depending on which one you use) - change between those versions. It only requires one use of a class somewhere that was not used before or an introduction of an additional list of something inside of some class and the binary size increases. Go diff the source directory of your C:\Program Files (x86)\Embarcadero\Studio\22.0 and C:\Program Files (x86)\Embarcadero\Studio\23.0 directories and check for yourself. Or build with a map file and then diff the map file to find these changes. Also - and this might be marginal but contribute to the overall increase: they changed the count and index of all collection types to NativeInt which means that some instructions regarding those might be a few bytes larger on 64bit (see some x86-64 instruction reference of your choice for details). Otherwise, when I think about it it might also save a few bytes because it does no do register widening anymore on 64bit. So take this last paragraph with a grain of salt and consider it just additional information. I would guess a few fixes and new features here and there can easily add up to 300K more binary size - especially with the general issue the Delphi compiler has with generics - see RSP-16520.

Marketing people don't fix bugs 😉

TBH IMO using years is kinda ok and a version number where the number after the dot means "update to that version". What was marketing bs was the XE numbering and then later making the 10 minor versions actually major versions - combining that with city names just made things more confusing (man, I still have to think if Tokyo or Rio was first...). Funny enough as far as I can see the IDEs in 11 and 12 don't reference the city name anywhere.

CreateProcess and IPC

LSP has an official protocol though I don't know exactly which version and which subset Embarcadero supports - but it's enough to let you use it in VS Code.

Indirectly does not matter for this algorithm because it directly sorts a vector of integer or float - and DB keys are organized in a different layout. Again, the question was not in sorting millions of elements of data but strictly sorting arrays of integer or float.

A serious question because many sort benchmarks are so obsessed with sorting large arrays/vectors of just integers and floats: Do people in reality really have these kinds of data that need to be sorted?

Using 10.4 you can do this with the following code: TArray.Sort<yourtype>(list.PList^, list.Comparer, index, count);

I reported that issue years ago but unfortunately it still exists - the report contains the exact steps that lead to this at the end and thus might help to avoid it in the future:

No, but it should be pretty simple to sort the ItemGroup node in the groupproj file according to your needs.

fwiw all parameters but passing the mapfile name (since the exe name is most likely the same and directly next to it) and the -bind parameter (which causes the PE header in the binary to be updated in order for VTune to properly use the pdb) are optional. VTune has some very extensive documentation and even a tour inside the application that teaches the basics

Putting the line number to the left into a gutter just like in the editor would save a lot of vertical space - take a look at the Notepad++ search results window