Apple Developer Transition Kit

[Igor Kokarev]

skalogryz,

Thanks, I'll try NSProcessInfo processInfo.processorCount
It would be a simpliest code for macOS.

Jonas,

Did you see any articles or confirmations about using of 8-cores in Apple DTK or M1?

"The Geekbench 5 result reports the DTK as having only four cores while it is known that the A12Z has, in fact, eight CPU cores. It is very well possible that Rosetta 2 is seeing only the four high performance cores and not the efficiency ones."

https://www.notebookcheck.net/First-A12Z-Bionic-DTK-Geekbench-5-benchmarks-show-Apple-s-transition-holds-immense-promise-only-a-28-in-drop-seen-in-single-core-score-compared-to-the-MacBook-Air-2020.477595.0.html

[Jonas Maebe]

You don't need external confirmation since you have a DTK yourself. Just create a program that starts 7 threads that execute "while true do ;" (and do the same in the main program) and look at the cpu usage reported by top (or Activity Viewer). Then try the same with 3 threads and 11 threads. You'll get ~390%/~790%/~790% reported cpu usage for respectively 4/8/12 loops executing concurrently.

[Igor Kokarev]

Jonas,

You're right. It's easy to check.

The only question - performance of last 4 cores. Probably the total performance of these high-efficienty cores would be as 2 high-performance cores.

[Igor Kokarev]

What about processorCount?

The code might look like thise

Code: Pascal  [Select][+][-]

1. uses
2.   CocoaAll;
3. {$modeswitch objectiveC2}
4.  
5. begin
6.   writeln('proc count: ', NSProcessInfo processInfo.processorCount);
7. end.  

skalogryz,

I can't compile this code on any Mac.

[skalogryz]

Code: Pascal  [Select][+][-]

1. uses
2.   CocoaAll;
3. {$modeswitch objectiveC2}
4.  
5. begin
6.   writeln('proc count: ', NSProcessInfo.processInfo.processorCount);
7. end.

[JdeHaan]

The mode switch should be above the uses clause.

Code: Pascal  [Select][+][-]

1. program processorcount;
2. {$modeswitch objectiveC2}
3.  
4. uses
5.   CocoaAll;
6.  
7. begin
8.   writeln('proc count: ', NSProcessInfo.processInfo.processorCount);
9. end.
10.  

[Igor Kokarev]

Thanks, it works now.

[Jonas Maebe]

Jonas,

You're right. It's easy to check.

The only question - performance of last 4 cores. Probably the total performance of these high-efficienty cores would be as 2 high-performance cores.

Not necessarily. Performance wins usually decrease exponentially as cores become more powerful/complex, so it could easily be more than that. It also illustrates the limited use of a singular "processorcount" value. Other cases where it means little is in case of NUMA configurations and hyperthreading.

[trev]

HW selectors for sysctlbyname which are useful in this context:

* hw.ncpu   - The maximum number of processors that could be available this boot
* hw.activecpu   - The number of processors currently available for executing threads
* hw.physicalcpu - The number of physical processors available in the current power management mode
* hw.logicalcpu  - The number of logical processors available in the current power management mode

See the Wiki article Accessing macOS System Information.

[Igor Kokarev]

Thanks! Great info. I'll learn it more.

[marcov]

Not necessarily. Performance wins usually decrease exponentially as cores become more powerful/complex, so it could easily be more than that. It also illustrates the limited use of a singular "processorcount" value. Other cases where it means little is in case of NUMA configurations and hyperthreading.

There are also some reports that the extreme bandwidth of the fast cores leads to memory bandwidth saturation, where the slower core could eat memory bandwidth of the faster cores.

https://www.anandtech.com/show/16252/mac-mini-apple-m1-tested

[Igor Kokarev]

Currently FPC trunk can compile to "arm64" target for macOS.

In the final release of Big Sur Apple compiles own apps in "arm64e". You can check it using
lipo -archs /Applications/Safari.app/Contents/MacOS/Safari

It seems that arm64e is a new generation of arm64:

- Pointer authentication
- Nested virtualization
- Advanced SIMD complex number support
- Improved Javascript data type conversion support
- A change to the memory consistency model
- ID mechanism support for larger system-visible caches

Is it possible that "arm64" will be declared as deprecated in nearest future?

Can FPC compile to arm64e ?

https://stackoverflow.com/questions/52624308/xcode-arm64-vs-arm64e

[Jonas Maebe]

In the final release of Big Sur Apple compiles own apps in "arm64e".

Apple has been doing that since several betas already (maybe even from the first beta, but I didn't have a DTK yet at that point).

It seems that arm64e is a new generation of arm64:

No, it's just an extension.

Is it possible that "arm64" will be declared as deprecated in nearest future?

Definitely not in the nearest future, since building your own applications for arm64e is not even supported yet by Apple itself: https://developer.apple.com/forums/thread/652340

Most likely not afterwards either.

Can FPC compile to arm64e ?

Currently only by using the LLVM backend.

[Igor Kokarev]

Jonas,

Thank you very much for the detailed reply!

[Igor Kokarev]

Jonas,

I plan to compile a final version of our app as Universal Binary (Intel + AARCH64).

You explained me how to configure cross compilation on Intel Mac.

What is better:
A. Use a stable Lazarus 2.0.10 with FPC Trunk 3.3.1?
B. Or Lazarus Trunk + FPC Trunk 3.3.1?

I guess that official release of Lazarus with FPC will not be released soon.