How to compile against ASM versions of System unit code?

[kaarigar 1]

The System unit has various conditional compile flags etc. One of them is PUREPASCAL define that I want to undefine so that ASM versions of the System functions would be compiled. I am specifically interested in the Pos function. The PUREPASCAL gets defined at the beginning as 

{$IF defined(CPUX86) and defined(ASSEMBLER)}
  {$DEFINE X86ASMRTL}
{$ELSE}
  {$DEFINE PUREPASCAL}
{$ENDIF}

How can I ensure that the PUREPASCAL doesn't get defined? I have tried and define CPUX86 and ASSEMBLER defines, but that doesn't seem to work. Does this require modifying the System unit? Any help is greatly appreciated.

[Leif Uneus 43]

What is your target platform?

If it is Win32, the ASM version will be chosen. 

[kaarigar 1]

I am compiling for Win64 target in Delphi Alexandria with latest update/patch. The intention is to have faster code with the help of assembly code, but I am not sure if that's what is achievable with what I am attempting.

[David Heffernan 2345]

If there are faster asm versions in the system unit, that work on x64, then they will be used. But you can't compile an x86 asm procedure in x64 and expect it to work. You need a bespoke x64 version. 

 

In other words, I don't think what you describe is going to be possible. 

 

What is your specific performance issue? 

[Leif Uneus 43]

The PUREPASCAL Pos code in Delphi 11 has been changed to a more optimised version, in fact the same code that the ASM version is based on. Using the PUREPASCAL version even in WIN32 would give the same execution speed as the ASM version. 

[Fr0sT.Brutal 900]

You can always extract any function from RTL unit and compile it separately.

[Stefan Glienke 2005]

This is a pointless endeavor unless you have some proof that the new code in Delphi 11 has a performance regression - the generated assembly code for the purepascal code is almost identical to the handwritten version before on x86 and all other platforms it should be significantly faster than the previous pure pascal implementation. (I should know - I did that change)

[kaarigar 1]

7 hours ago, Stefan Glienke said:

This is a pointless endeavor unless you have some proof that the new code in Delphi 11 has a performance regression - the generated assembly code for the purepascal code is almost identical to the handwritten version before on x86 and all other platforms it should be significantly faster than the previous pure pascal implementation. (I should know - I did that change)

Thank you for your response. No, I don't have any proof, nor do I know any assembly to even look for any proof or done any benchmarks. I was assuming that the the presence of the ASM blocks would indicate that it's purpose was to make code more efficient in terms of execution.

[kaarigar 1]

10 hours ago, David Heffernan said:

If there are faster asm versions in the system unit, that work on x64, then they will be used. But you can't compile an x86 asm procedure in x64 and expect it to work. You need a bespoke x64 version. 

 

In other words, I don't think what you describe is going to be possible. 

 

What is your specific performance issue? 

Yes, my mistake in asking mixing up X86 code with x64.

 

It's not really any performance issue that I have run into as such - it's that my application repeated search on strings inside a loop - and depending upon situation, there could be billions of computationally generated strings. I was checking that sure that the Pos function that gets called repeatedly is efficient.

[kaarigar 1]

17 hours ago, Leif Uneus said:

What is your target platform?

If it is Win32, the ASM version will be chosen. 

Yes! I misinterpreted that the conditional compile was for x64. My bad.

Edited May 24, 2022 by kaarigar

[David Heffernan 2345]

2 hours ago, kaarigar said:

It's not really any performance issue that I have run into as such - it's that my application repeated search on strings inside a loop - and depending upon situation, there could be billions of computationally generated strings. I was checking that sure that the Pos function that gets called repeatedly is efficient.

You should profile your program to find out where the bottleneck is. Human intuition is usually wrong in such matters.