Different builds for more recent processors and a little older ones

[daniel_sap]

Hi

I was thinking that if I can build different executables for people who bought more recent processors and those with older ones
may lead to some benefits, like
- people with newer cpus can take advantage of newer instructions and have faster app

I can put checks in the Web Installer for the current system and download the proper executable

Do you think this is good idea and is there something in FPC in this direction.

Also, I suppose a lot of new instructions are not used to have compatibility.

[paule32]

download FPC deluxe
and with a stub Bootstrap Compiler, you can Create FPC Version's for a wide range of FPC for different CPU's and different OS's.

Luck Luke
...

[Martin_fr]

Well, first check how much of an improvement that actually gets. Is it noticeable?

Also, are all of you routines affected, or is the speed gain limited to some few procedures?
If it is only some code, you can even include both versions of the procedure, and then decide at runtime which to call.

For Intel (and likely AMD) play with "loopalign = 32". Especially for very small loops with lots of iterations. Doing it for all your code may be counter productive.

[Thaddy]

- people with newer cpus can take advantage of newer instructions and have faster app

This is already possible/ has always been possible.
Only the very cutting edge CPU's may not be there yet.
Type fpc -ifco in a terminal/console
E.g. in trunk for x86_64 that gives you (fpu,cpu, optimizations):

Code: Bash  [Select][+][-]

1. NONE
2. SSE64
3. X86-64-V1
4. SSE3
5. SSSE3
6. SSE41
7. SSE42
8. X86-64-V2
9. AVX
10. FMA
11. AVX2
12. X86-64-V3
13. AVX512F
14. X86-64-V4
15.  
16. ATHLON64
17. X86-64
18. X86-64-V1
19. COREI
20. X86-64-V2
21. BOBCAT
22. COREAVX
23. JAGUAR
24. PILEDRIVER
25. EXCAVATOR
26. COREAVX2
27. X86-64-V3
28. ZEN
29. ZEN2
30. X86-64-V4
31. SKYLAKE-X
32. ICELAKE
33. ICELAKE-CLIENT
34. ICELAKE-SERVER
35. ZEN3
36. ZEN4
37. ZEN5
38.  
39. REGVAR
40. STACKFRAME
41. PEEPHOLE
42. LOOPUNROLL
43. TAILREC
44. CSE
45. DFA
46. STRENGTH
47. USERBP
48. ORDERFIELDS
49. FASTMATH
50. REMOVEEMPTYPROCS
51. CONSTPROP
52. USELOADMODIFYSTORE
53. UNUSEDPARA
54. FORLOOP

How the compiler is build and for what CPU does not matter. You can even generate code for more modern cpu's on a machine with a relatively old one: generate code that does not run on the cpu you used to compile....

[marcov]

Being 64-bit already raises the minimal instruction level considerably. I don't think the average code has much advantage from the extensions after that. A problem is also that some of those are not defined by ABI.

Some compression code that uses the bitscan and -count primitives might benefit in theory. Maybe a few newer instructions are slightly faster than older alternatives, but that will be rare.

Thaddy: the recompile is to make RTL/libraries also use that optimization level, not the compiler

[Thaddy]

@Marcov
With recent processors it is more about number of cores and parallelism and that is where FPC may lack a bit compared to some other languages with better - easy to use - parallel frameworks. But of course that is not CPU but software.
Over the past 20 years or so the most impressive improvements have come from the fpu improvements, not the cpu (Talking Intel/AMD, not ARM architecture). Basically vectors.

[MarkMLl]

With recent processors it is more about number of cores and parallelism and that is where FPC may lack a bit compared to some other languages with better - easy to use - parallel frameworks. But of course that is not CPU but software.
Over the past 20 years or so the most impressive improvements have come from the fpu improvements, not the cpu (Talking Intel/AMD, not ARM architecture). Basically vectors.

And the SSE etc. version doesn't appear in the ELF header (for unix... can't speak for Windows).

I think that broadly speaking, the best way to do something like this is to have separate loadable libraries for each major target.

MarkMLl

[MarkMLl]

download FPC deluxe
and with a stub Bootstrap Compiler, you can Create FPC Version's for a wide range of FPC for different CPU's and different OS's.

How's that supposed to help him decide on a strategy for what processor variants he builds code for and how he distributes the resulting binaries?

MarkMLl

[daniel_sap]

- people with newer cpus can take advantage of newer instructions and have faster app

This is already possible/ has always been possible.
Only the very cutting edge CPU's may not be there yet.
Type fpc -ifco in a terminal/console
E.g. in trunk for x86_64 that gives you (fpu,cpu, optimizations):

Code: Bash  [Select][+][-]

1. NONE
2. SSE64
3. X86-64-V1
4. SSE3
5. SSSE3
6. SSE41
7. SSE42
8.  
9. AVX
10. FMA
11. AVX2
12. X86-64-V3
13. AVX512F
14. X86-64-V4
15.  
16. ATHLON64
17. X86-64
18. X86-64-V1
19. COREI
20. X86-64-V2
21. BOBCAT
22. COREAVX
23. JAGUAR
24. PILEDRIVER
25. EXCAVATOR
26. COREAVX2
27. X86-64-V3
28. ZEN
29. ZEN2
30. X86-64-V4
31. SKYLAKE-X
32. ICELAKE
33. ICELAKE-CLIENT
34. ICELAKE-SERVER
35. ZEN3
36. ZEN4
37. ZEN5
38.  
39. REGVAR
40. STACKFRAME
41. PEEPHOLE
42. LOOPUNROLL
43. TAILREC
44. CSE
45. DFA
46. STRENGTH
47. USERBP
48. ORDERFIELDS
49. FASTMATH
50. REMOVEEMPTYPROCS
51. CONSTPROP
52. USELOADMODIFYSTORE
53. UNUSEDPARA
54. FORLOOP

How the compiler is build and for what CPU does not matter. You can even generate code for more modern cpu's on a machine with a relatively old one: generate code that does not run on the cpu you used to compile....

If I understand it right
I can specify some optimizations to be used - for example X86-64-V2
And this will tell the FPC to compile with instructions introduced from certain year - for example every AMD and Intel cpu after 2020 will support the compiled executable.

And if I want to detect to which computer to ship it, I have to check the year of cpu or some cpu info

[MarkMLl]

And if I want to detect to which computer to ship it, I have to check the year of cpu or some cpu info

And that has to be done at runtime.

MarkMLl

[daniel_sap]

And if I want to detect to which computer to ship it, I have to check the year of cpu or some cpu info

And that has to be done at runtime.

MarkMLl

Yes, the check will be done later by application run on the specific computer - for example Web(Online) Installer

[daniel_sap]

Being 64-bit already raises the minimal instruction level considerably. I don't think the average code has much advantage from the extensions after that. A problem is also that some of those are not defined by ABI.

Some compression code that uses the bitscan and -count primitives might benefit in theory. Maybe a few newer instructions are slightly faster than older alternatives, but that will be rare.

Thaddy: the recompile is to make RTL/libraries also use that optimization level, not the compiler

As I understand, it looks like there is not much benefit to build different executable for newer and older CPUs.
So, it looks like the CPUs manufactured in the recent years improve the speed, the power consumption, may be faster execution of old instructions,
but not providing some new useful instruction which make big difference