Hello,

first and foremost, many thanks to the creators and contributors of FPC and Lazarus, who enabled me to release my product natively for Apple Silicon only one day after receiving an M1 Mac. Fantastic work! FPC and Lazarus both run natively and work very well.

According to Geekbench, the single core performance on the new Mac is around 1.8x as fast as my Intel Mac. Multicore is also much faster. I wonder why I don't see the speed increase in compiling though. Yes I am using different FPC and XCode versions, but I wonder what else could have an influence? My project is very large and not divided into packages, so I frequently need to recompile the whole project.

I would be most grateful for any performance tips.

Cheers,
Tobias

Tobias Giesen wrote

According to Geekbench, the single core performance on the new Mac is around 1.8x as fast as my Intel Mac.

Geekbench scores cannot be compared across different architectures.

I wonder why I don't see the speed increase in compiling though.

The fact that you get similar speed on a cpu that probably uses quite a bit less than half the power of your previous one is quite impressive.

Jonas

Large parts of FPC are memory throughput limited so I suspect the M1 is not that much better in this regard, not to mention that most likely the AAarch code generator is worse than the x86 one. x86 received a lot of work in this field.

Maybe it's possible that you build using an LLVM compiler the FPC with native backend. As I do not use macOS, I have no clue how to do this though.

Hi,
many thanks for the replies! I actually think most of the time is used by clang for assembling. If I can find out more precise details, I will let you know. And it is already a little bit faster on M1 than on my Intel.

Kind Regards,

Tobias Giesen
Super Flexible Software GmbH & Co. KG

----

Kind Regards,
Tobias Giesen

Super Flexible Software GmbH & Co. KG
Buddenstr. 29-31
48143 Münster, Germany
www.superflexible.com
www.tgtools.com

----------------------------------------------------------- Registered at register court Münster as HRA 9716
Liability / general partner: TGTools GmbH
Registered at register court Münster as HRB 17763 Directors: Tobias Giesen and Claudia Giesen

Op 2020-11-21 om 14:15 schreef Florian Klämpfl via fpc-pascal:

Some memory throughput details are here:
https://www.anandtech.com/show/16252/mac-mini-apple-m1-tested

M1 is listed as 96ns memory latency through a 128-bit bus.

A Zen3 (ryzen 5x00) should be 67-83ns depending on type of memory:

https://www.anandtech.com/show/14605/the-and-ryzen-3700x-3900x-review-raising-the-bar/2

which in dual channel mode afaik is also 128-bit.

Maybe it's possible that you build using an LLVM compiler the FPC with native backend. As I do not use macOS, I have no clue how to do this though.

Do the x86(_64) OSX(I) FPC compilers use binary object writers?

Marco van de Voort wrote

Do the x86(_64) OSX(I) FPC compilers use binary object writers?

No.

Jonas

On Nov 21, 2020, at 6:15 AM, Florian Klämpfl via fpc-pascal wrote: Large parts of FPC are memory throughput limited so I suspect the M1 is not that much better in this regard, not to mention that most likely the AAarch code generator is worse than the x86 one. x86 received a lot of work in this field.

What does that mean exactly to be "memory throughput limited"? What part of the compilation process does this affect exactly?

Regards,
Ryan Joseph

For compiling the compiler itself, excluding assembling and linking, a compiler compiled using the LLVM backend (but that generates code using our native code generator (*) ) is 18.85% faster than one compiled using our native code generator (on a Developer Transition Kit, but I guess it will be similar on the M1).

If you include assembling and linking (which you obviously always have to do), the speed difference shrinks to 8.5%. So more time is spent in the assembler (clang) and ld than in the compiler.

As to how to do build a compiler on macOS that uses the LLVM backend, that's the same as on Linux, except that you don't need special command line options to find libgcc: https://wiki.freepascal.org/LLVM

Jonas

(*) using the LLVM backend is slower because clang's code generator is
much slower than FPC's.

It sounds like the LLVM backend is superior so is it the plan to start distributing compiler releases built from LLVM? What are the plans for the native code generator if it's being outperformed by the LLVM backend?

Regards,
Ryan Joseph

All. FPC typically uses several ten MBs and accesses it rather randomly.

Ryan Joseph wrote

It sounds like the LLVM backend is superior so is it the plan to start distributing compiler releases built from LLVM?

Not in the near future.

What are the plans for the native code generator if it's being outperformed by the LLVM backend?

See https://wiki.freepascal.org/LLVM#Frequently_Asked_Questions

Jonas

Ryan Joseph wrote

What are the plans for the native code generator if it's being outperformed by the LLVM backend?

Only the generated code is a little bit faster. The compiler using LLVM is ~10 times slower.

On Nov 21, 2020, at 9:23 AM, Florian Klämpfl via fpc-pascal wrote: All. FPC typically uses several ten MBs and accesses it rather randomly.

Wow 10-100 MB is enough to limit speed due to memory access times? I understand there is some limit to how much memory can be accessed per X period of time but I thought it was measured in GB before getting penalties. Shows what I know. :)

I don't see the compiler changing in architecture however so we'll just wait for faster hardware. ;)

Regards,
Ryan Joseph

L1 cache is typically only a few ten kB, L2 several hundred kB, L3 several MB.

On Nov 21, 2020, at 9:33 AM, Florian Klämpfl via fpc-pascal wrote: L1 cache is typically only a few ten kB, L2 several hundred kB, L3 several MB.

Oh I see what you mean. Yeah cache miss is a problem that would be not feasible to fix in the compiler for the most part.

I guess this means FPC has reached more or less maximum speeds until memory access speeds are improved in the hardware.

Regards,
Ryan Joseph

In r47526, I implemented support of the prefetch intrinsic on aarch64. On my Raspi4 it reduced make cycle time by 25 % (!). I would be very interested to get numbers for the M1.

25% ?!

Well...
If the compiler can make such a difference, should we still bother with micro-optimizations in code then ?

Michael.

Yes. I were also baffled and tested several times but numbers didn‘t change. This is why I would like to see numbers from others.

Well... If the compiler can make such a difference,

This are the big low hanging fruits, their are only a few :) In particular the compiler benefits a lot from this as it iterates linked lists a lot.

should we still bother with micro-optimizations in code then ?

I am always against micro-optimising code, this should do the compiler though prefetch is also a matter of inserting the intrinsic in your code. FPC can do this automatically but so far it is disabled as it is overall not beneficial.

Michael._______________________________________________ fpc-pascal maillist - https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Hello Florian,
many thanks for this!

To compare performance, is it sufficient to add the FTP=xxx parameter and point it to the different ppca64 versions?

And should I compile the older source snapshort with the older version, and today's snapshot with the newer ppca64?

I just want to do the test correctly.

Cheers,
Tobias

----

In r47526, I implemented support of the prefetch intrinsic on aarch64. On my Raspi4 it reduced make cycle time by 25 % (!). I would be very interested to get numbers for the M1.

Just curious, how does the "prefetch intrinsic" help with iterating linked lists?

Regards,
Ryan Joseph

Florian Klämpfl wrote

L1 cache is typically only a few ten kB, L2 several hundred kB, L3 several MB.

Some real-world comparisons in human units:

https://gist.github.com/hellerbarde/2843375

https://www.pcgamer.com/heres-a-neat-trick-for-understanding-how-long-computer-processes-take/

If fetching the next instruction from the next location in L1 cache took 1 second, getting it from main memory would take over a minute and a half. Getting it from an SSD, a weekend. Getting it from a hard disk, about 4 months.

By prefetching the next element in the background while processing the current element. Since the elements are not necessarily placed behind each other in memory, the processor's built-in prefetcher can't handle this.

Jonas