10 ноября 2020 года произошло во многом эпохальное событие в индустрии микропроцессоров - компания Apple презентовала новый Mac Mini, главной фишкой которого являлся чип собственной разработки Apple M1. Данный процессор, без преувеличения, является знаковым достижением для экосистемы ARM - наконец-то был сделан чип, обошедший конкурентов из Intel в той нише, где архитектура x86 доминировала десятилетия.
Но для нас главным интересом является не сам процессор M1, а технология двоичной трансляции Rosetta 2, разработанная с целью запуска legacy x86 кода, не успевшего переехать на архитектуру ARM. Компания Apple имеет большой опыт в разработке решений по двоичной трансляции и является признанным лидером в данной области. Первая версия двоичного транслятора Rosetta появилась в 2006-ом году, когда помогла компании Apple совершить переход с архитектуры PowerPC на x86. И хотя в этот раз гостевая и целевая платформы отличались от тех, которые были в 2006-ом, очевидно, что весь опыт, накопленный инженерами Apple за эти годы, был учтён и вложен в следующую версию Rosetta 2. Тем интреснее было сравнить решение от Apple с аналогичным продуктом Huawei ExaGear (ведущего свою родословную от Eltechs ExaGear), разрабатываемого нашей командой. Заодно, мы оценили производительность двоичной трансляции из x86 в ARM от компании Microsoft (входящей в состав MS Windows 10 для Arm устройств) на лэптопе Huawei MateBook E. На текущий момент, это все известные нам решения по двоичной трансляции из X86 в ARM, доступные на широком рынке.
Т.к. все решения изначально созданы под разные операционные системы (Huawei Exagear – под Linux, Apple Rosetta 2 - под MacOS, Microsoft binary translator – под MS Windows), возникла необходимость найти корректный метод сравнения, т.к. напрямую провести запуски было невозможно. Мы приняли за основу метрику «эффективности трансляции» - это отношение показателя времени исполнения бенчмарка в нативном для платформы режиме (ARM в нашем случае) ко времени запуска этого же бенчмарка в x86-кодах запущенного под двоичным транслятором(или же обратная величина в случае измерения попугаев «больше-лучше»). Иными словами, мы сравнивали то, сколько процентов от нативного исполнения достигает бенчмарк в режиме двоичной трансляции. Такой же метрикой пользовались эксперты с сайта Anandtech, выпустившие обзорную статью про Apple M1, где также были приведены цифры производительности Rosetta 2.
Все замеры проведены в однопоточном режиме, т.к. для нас было важно замерить именно качество оттранслированного кода, насколько он уступает нативному.
Huawei ExaGear vs Apple Rosetta 2
Итак, начнём сравнение Huawei ExaGear с Apple Rosetta 2 на Apple MacBook Pro (M1). Тесты под Rosetta 2 запускаются в родной MacOS BigSur 11.1, тесты под ExaGear - в виртуалке с Linux kernel 5.4.1.
Geekbench 5.4.1 (чем выше – тем лучше):
Bench name |
ARM64 MacOS |
Rosetta 2 (x86) |
Rosetta 2 efficiency |
ARM64 Linux (VM) |
Exagear (x86) |
Exagear efficiency |
AES-XTS |
2769 |
1720 |
62.1% |
2703 |
1823 |
67.4% |
Text Compression |
1502 |
1319 |
87.8% |
1438 |
1349 |
93.8% |
Image Compression |
1356 |
1056 |
77.9% |
1335 |
1230 |
92.1% |
Navigation |
1716 |
1678 |
97.8% |
1717 |
1605 |
93.5% |
HTML5 |
1642 |
1066 |
64.9% |
1717 |
1302 |
75.8% |
SQLite |
1400 |
1000 |
71.4% |
1328 |
1229 |
92.6% |
PDF Rendering |
1600 |
1324 |
82.8% |
1738 |
1464 |
84.2% |
Text Rendering |
1778 |
1290 |
72.6% |
1726 |
1480 |
85.8% |
Clang |
1661 |
1244 |
74.9% |
1738 |
1335 |
76.8% |
Camera |
1612 |
1278 |
79.3% |
1464 |
1148 |
78.4% |
N-Body Physics |
1789 |
1503 |
84.0% |
1830 |
1616 |
88.3% |
Rigid Body Physics |
1772 |
1352 |
76.3% |
1690 |
1176 |
69.6% |
Gaussian Blur |
1407 |
1251 |
88.9% |
1435 |
1297 |
90.4% |
Face Detection |
2215 |
1500 |
67.7% |
2216 |
1632 |
73.7% |
Horizon Detection |
1964 |
1268 |
64.6% |
1879 |
1386 |
73.8% |
Image Inpainting |
3214 |
2893 |
90.0% |
3345 |
2903 |
86.8% |
HDR |
2486 |
2250 |
90.5% |
2761 |
2690 |
97.4% |
Ray Tracing |
2553 |
1970 |
77.2% |
2055 |
1992 |
96.9% |
Structure from Motion |
1406 |
1068 |
76.0% |
1507 |
1150 |
76.3% |
Speech Recognition |
1601 |
1371 |
85.6% |
1485 |
1355 |
91.3% |
Machine Learning |
1243 |
713 |
57.4% |
1229 |
727 |
59.2% |
GeoMean |
76.9% |
82.4% |
Как видно, средняя производительность Huawei ExaGear ( 82.4%) обгоняет Apple Rosetta 2 (76.9%), причём проигрывает ExaGear только на 4-х тестах из 21-го – Navigation, Camera, Rigid Body Physics и Image Inpainting.
Тут надо сделать небольшое, но достаточно интересное отступление. Дело в том, что при более детальном изучении процессора M1 можно обнаружить, что несмотря на то, что он официально вышел только в ноябре 2020-го года (а значит его система команд была зафиксирована задолго до этого момента, явно не позднее 2019-го года), он содержит в себе набор расширений архитектуры ArmV8.7, которая официально была принята и опубликована только осенью 2020-го года. Причём существенная часть этого расширения является ничем иным, как аппаратной поддержкой двоичной трансляции, призванной упростить трансляцию некоторых операций из архитектуры x86. Т.е. компания Apple разрабатывала процессор с расширением, которое на тот момент не было официальным. Более того, при внимательно ретроспективном взгляде на более ранние расширения видно, что ArmV8.5 и ArmV8.4 также включали в себя операции для поддержки двоичной трансляции. Таким образом очевидно, что компания Apple достаточно давно в кооперации с Arm Ltd. работало над аппартной поддержкой своего решения. Apple Rosetta 2 использует все данные возможности и поэтому имеет определённое преимущество, по сравнению с Huawei Exagear, который данные расширения не использует.
Именно поэтому данные 4 теста Apple Rosetta 2 исполняет эффективнее. Но тем не менее, на остальных тестах, даже с учётом имеющегося гандикапа у решения от Apple, Huawei ExaGear показывает более высокие результаты.
Также стоит отметить, что цифры производительности в нативном Arm-режиме на MacOS и Linux в целом достаточно близки, что подтверждает общую корректность нашего подхода по сравнению производительности двоичных трансляторов.
Далее, сравним запуски на SpecCPU2006 и SpecCPU2017. Измеряется время работы каждого подтеста в секундах. Исключены бенчмарки, написанные на Fortran.
SpecCPU2006 (секунды)
Компилятор: clang 11.0 -O3 –flto
INT tests |
ARM64 MacOS |
Rosetta 2 (x86) |
Rosetta 2 efficiency |
ARM64 Linux (VM) |
ExaGear (x86) |
ExaGear efficiency |
400.perlbench |
157 |
218 |
72.0% |
145 |
166 |
87.3% |
401.bzip2 |
248 |
326 |
76.1% |
247 |
282 |
87.6% |
429.mcf |
106 |
118 |
89.8% |
129 |
123 |
104.9% |
445.gobmk |
178 |
198 |
89.9% |
183 |
193 |
94.8% |
456.hmmer |
159 |
170 |
93.5% |
164 |
142 |
115.5% |
458.sjeng |
246 |
300 |
82.0% |
253 |
281 |
90.0% |
462.libquantum |
94 |
107 |
87.9% |
101 |
128 |
78.9% |
464.h264ref |
203 |
328 |
61.9% |
201 |
271 |
74.2% |
471.omnetpp |
146 |
179 |
81.6% |
173 |
193 |
89.6% |
473.astar |
184 |
203 |
90.6% |
196 |
201 |
97.5% |
483.xalancbmk |
82 |
104 |
78.8% |
96 |
112 |
85.7% |
GeoMean Int |
81.7% |
90.8% |
||||
FP tests |
||||||
433.milc |
95 |
130 |
73.1% |
98 |
127 |
77.2% |
444.namd |
139 |
172 |
80.8% |
139 |
164 |
84.8% |
447.dealII |
108 |
117 |
92.3% |
115 |
151 |
76.2% |
450.soplex |
91 |
104 |
87.5% |
95 |
107 |
88.8% |
453.povray |
60 |
78 |
76.9% |
52 |
65 |
80.0% |
470.lbm |
113 |
119 |
95.0% |
114 |
99 |
115.2% |
482.sphinx3 |
194 |
207 |
93.7% |
195 |
215 |
90.7% |
GeoMean FP |
85.2% |
86.7% |
SpecCPU2017 (секунды)
Компилятор: clang 11.0 -O3 –flto
INT tests |
ARM64 MacOS |
Rosetta 2 (x86) |
Rosetta 2 efficiency |
ARM64 Linux(VM) |
ExaGear (x86) |
ExaGear efficiency |
500.perlbench_r |
216 |
282 |
76.6% |
210 |
241 |
87.1% |
502.gcc_r |
125 |
164 |
76.2% |
125 |
153 |
81.7% |
505.mcf_r |
202 |
235 |
86.0% |
217 |
231 |
93.9% |
520.omnetpp_r |
277 |
360 |
76.9% |
295 |
324 |
91.0% |
523.xalancbmk_r |
166 |
204 |
81.4% |
189 |
197 |
95.9% |
525.x264_r |
154 |
176 |
87.5% |
161 |
189 |
85.2% |
531.deepsjeng_r |
175 |
221 |
79.2% |
190 |
197 |
96.4% |
541.leela_r |
282 |
294 |
95.9% |
285 |
277 |
102.9% |
557.xz_r |
275 |
319 |
86.2% |
307 |
335 |
91.6% |
GeoMean Int |
82.7% |
91.6% |
||||
FP tests |
||||||
508.namd_r |
111 |
134 |
82.8% |
111 |
133 |
83.5% |
510.parest_r |
308 |
331 |
93.1% |
304 |
336 |
90.5% |
511.povray_r |
211 |
320 |
65.9% |
196 |
253 |
77.5% |
519.lbm_r |
121 |
153 |
79.1% |
127 |
142 |
89.4% |
526.blender_r |
149 |
179 |
83.2% |
163 |
175 |
93.1% |
538.imagick_r |
210 |
345 |
60.9% |
227 |
271 |
83.8% |
544.nab_r |
156 |
186 |
83.9% |
150 |
174 |
86.2% |
GeoMean FP |
77.7% |
86.1% |
Как видим, на SpecCPU2006/2017 ситуация аналогична тестам на Geekbench – в среднем Huawei ExaGear обыгрывает Apple Rosetta 2, хотя на отдельных подтестах ситуация обратная.
Huawei ExaGear vs Microsoft binary translator
Теперь сравним производительность Huawei ExaGear с двоичным транслятором от Microsoft на Huawei MateBook E.
ExaGear запускается в окружении WSL, транслятор от Microsoft в родной MS Windows 10.
В запусках ExaGear в окружении WSL обнаружилась проблема, что WSL не предоставляет используемые нами для профилирования таймеры, из-за чего не включается режим дооптимизации кода и ExaGear не демонстрирует максимальные цифры производительности. Потери скорости в таком случае можно оценить в 10-20% в зависимости от бенчмарка. Тем не менее, с учётом вышеприведённых результатов сравнения с Apple Rosetta 2, общая картина будет ясна.
Geekbench 5.4.1 (чем выше – тем лучше):
Bench name |
ARM64 Windows |
MS BT (x86) |
MS BT efficiency |
ARM64 WSL |
ExaGear (x86) |
ExaGear efficiency |
AES-XTS |
872 |
437 |
50.1% |
892 |
437 |
49.0% |
Text Compression |
514 |
381 |
74.1% |
518 |
451 |
87.1% |
Image Compression |
577 |
328 |
56.8% |
606 |
433 |
71.5% |
Navigation |
402 |
393 |
97.8% |
522 |
502 |
96.2% |
HTML5 |
517 |
224 |
43.3% |
522 |
371 |
71.1% |
SQLite |
534 |
240 |
44.9% |
565 |
412 |
72.9% |
PDF Rendering |
515 |
253 |
49.1% |
574 |
462 |
80.5% |
Text Rendering |
530 |
264 |
49.8% |
544 |
430 |
79.0% |
Clang |
485 |
187 |
38.6% |
601 |
405 |
67.4% |
Camera |
437 |
221 |
50.6% |
479 |
308 |
64.3% |
N-Body Physics |
390 |
253 |
64.9% |
390 |
317 |
81.3% |
Rigid Body Physics |
634 |
299 |
47.2% |
717 |
485 |
67.6% |
Gaussian Blur |
279 |
217 |
77.8% |
282 |
238 |
84.4% |
Face Detection |
598 |
301 |
50.3% |
657 |
387 |
58.9% |
Horizon Detection |
484 |
235 |
48.6% |
542 |
331 |
61.1% |
Image Inpainting |
580 |
419 |
72.2% |
775 |
504 |
65.0% |
HDR |
637 |
481 |
75.5% |
1035 |
843 |
81.4% |
Ray Tracing |
758 |
296 |
39.1% |
762 |
513 |
67.3% |
Structure from Motion |
379 |
203 |
53.6% |
457 |
289 |
63.2% |
Speech Recognition |
346 |
283 |
81.8% |
355 |
312 |
87.9% |
Machine Learning |
252 |
108 |
42.9% |
240 |
128 |
53.3% |
GeoMean |
55.6% |
70.9% |
SpecCPU2017 (секунды)
Компилятор: clang 11.0 -O3 -flto
INT tests |
ARM64 Windows |
MS BT (x86) |
MS BT efficiency |
ARM64 WSL |
ExaGear (x86) |
ExaGear efficiency |
500.perlbench_r |
824 |
1526 |
54.0% |
800 |
1042 |
76.8% |
502.gcc_r |
716 |
1119 |
64.0% |
690 |
820 |
84.1% |
505.mcf_r |
781 |
1069 |
73.1% |
792 |
992 |
79.8% |
520.omnetpp_r |
1280 |
2025 |
63.2% |
1186 |
1414 |
83.9% |
525.x264_r |
460 |
771 |
59.7% |
481 |
638 |
75.4% |
531.deepsjeng_r |
507 |
711 |
71.3% |
524 |
629 |
83.3% |
541.leela_r |
564 |
897 |
62.9% |
547 |
652 |
83.9% |
557.xz_r |
733 |
938 |
78.1% |
733 |
827 |
88.6% |
GeoMean Int |
65.4% |
81.9% |
||||
FP tests |
||||||
508.namd_r |
423 |
698 |
60.6% |
429 |
619 |
69.3% |
510.parest_r |
1006 |
1274 |
79.0% |
970 |
1179 |
82.3% |
511.povray_r |
808 |
1540 |
52.5% |
761 |
1027 |
74.1% |
519.lbm_r |
428 |
767 |
55.8% |
429 |
549 |
78.1% |
526.blender_r |
474 |
688 |
68.9% |
484 |
716 |
67.6% |
538.imagick_r |
560 |
1075 |
52.1% |
566 |
847 |
66.8% |
544.nab_r |
522 |
1050 |
49.7% |
517 |
617 |
83.8% |
GeoMean FP |
59.0% |
74.3% |
Сборка SpecCPU2006 под Windows вызвала многочисленные ошибки компиляции. Поэтому было решено не тратить время на запуск данного бенчмарка при наличии результатов для SpecCPU2017, которые в целом достаточно идентичны SpecCPU2006.
Резюме
Инженеры компании Apple выпустили не только выдающийся процессор, но и снабдили его очень приличным двоичным транслятором для запуска x86-приложений, показывающим достойные результаты производительности. Тем не менее, Huawei ExaGear уверенно обыгрывает Apple Rosetta 2.
Решение от компании Microsoft существенно уступает по производительности вышеуказанным оппонетам, что достаточно ожидаемо, ввиду отсутствия такого большого опыта в разработке двоичных трансляторов.
Комментарии (27)
true-grue
10.09.2021 15:47+3Время трансляции не сравнивалось, это любопытный момент. Есть известные унивесальные приемы в духе супероптимизации, позволяющие получить хороший результат SBT-трансляции ценой весьма длительного времени работы транслятора.
vadik_lyutiy
10.09.2021 15:57+1В exagear в данных запусках нет никакой офлайн трансляции. Все затраты на трансляцию увеличивают время работы теста. То есть тут только runtime трансляция.
true-grue
10.09.2021 15:59В Rosetta 2, насколько я знаю, гибрид SBT/DBT, это учитывалось при сравнении?
vadik_lyutiy
10.09.2021 16:02Exagear использовал только DBT. Rosetta бралась как есть. Если она и использует SDT, то это только ей в плюс дало бы.
junari
10.09.2021 18:46Для arm64 в линуксе еще есть box64, который позволяет запускать программы для amd64. Или эта программа из другого разряда?
Будет ли хуавеевская программа доступна для других платформ арм? Или может быть даже открыты исходники?
Armmaster Автор
10.09.2021 19:36Или эта программа из другого разряда?
Да, можно и так сказать. box64 исторически был заточен на запуск игр на ARM платформе. Там применяются немного другие подходы. Т.е. это в целом в ту же степь, но всё же отличия существенные. Я не уверен, что там те же Spec CPU 2017 можно нормально запустить по итогу.
Будет ли хуавеевская программа доступна для других платформ арм? Или может быть даже открыты исходники?
В перспективе такой вариант возможен. Но пока только для платформ от Huawei.
RedSock
11.09.2021 00:48Не особо много я и понял из данной статьи. Но меня смущает то, что ExaGear "от Huawei" не работает на андроид устройствах от Huawei. Подскажите, с чем связано такое ограничение?
antag
11.09.2021 20:44+1Маленькое замечание. Не хватает теста 403.gcc из SPEC CPU 2006.
Результаты ExaGear удивляют, что так прилично превзошли Rosetta. Но если эффективность ExaGear уже 90% на SPEC 2017 для M1, тогда существенного потенциала для дальнейшего роста эффективности там уже нет.
Armmaster Автор
12.09.2021 00:16+1Маленькое замечание. Не хватает теста 403.gcc из SPEC CPU 2006.
Зоркий глаз!) Там на сборке под MacOS вылез сегфолт из-за баги коде самого теста. Не стали с этим заморачиваться и просто выкинули.
тогда существенного потенциала для дальнейшего роста эффективности там уже нет
Если разговор про Розетту, то потенциал там примерно к 100% стремится. Но это очень сложная задача, конечно же, так как каждый следующий процент перфа будет даваться всё сложнее и сложнее
Viknet
11.09.2021 21:26+1Любопытные результаты. Спасибо за статью.
Смущает только выборочное приведение тестов SPEC, что наводит на мысли о черрипикинге (хотя этим страдают абсолютно все обзоры), и большая разница эффективности между ARM64 Linux (VM) и ARM64 WSL, которой, на мой дилетанский взгляд, не должно быть вообще.
Ну и было бы интересно увидеть, какое решение (Rosetta 2 vs. ExaGear) потребляет больше памяти для одних и тех же задач, а также посмотреть на производительность JIT, например в браузерных тестах. Если такие сравнения уже делались, поделитесь, пожалуйста ссылками.
Armmaster Автор
12.09.2021 00:26Смущает только выборочное приведение тестов SPEC, что наводит на мысли о черрипикинге
Вопрос о чём, о том, что фортрановские тесты исключены? Там причина единственная- их надо было отдельно собирать через flang. Ковыряться с этим и тратить время просто посчитали излишним, нам же ещё и работать надо. На том же Anandtech'e точно такие же результаты приведены без фортрановских тестов. Так что всё честно, никакого черрипикинга.
Ну и было бы интересно увидеть, какое решение (Rosetta 2 vs. ExaGear) потребляет больше памяти для одних и тех же задач, а также посмотреть на производительность JIT, например в браузерных тестах.
Для тестов памяти надо отдельно заморачиваться. А т.к. обычно она не является главной проблемой, то особо нет интереса для такого рода замеров нет. Все статьи по бинарке обычно именно про перформанс кода, т.к. это самое сложное.
Что касается JIT и браузерных тестов - это, безусловно, интересные сравнения. Тут правда возникают опять проблемы с идентичностью окружений (даже для спеков вылезло немало проблем), но они в каком-то приближении решаемы. Возможно, в будущем опубликуем результаты таких замеров.
Viknet
12.09.2021 00:36Для тестов памяти надо отдельно заморачиваться. А т.к. обычно она не является главной проблемой, то особо нет интереса для такого рода замеров нет. Все статьи по бинарке обычно именно про перформанс кода, т.к. это самое сложное.
Это может быть важным параметром, если ExaGear, допустим, потребляет 2x RAM от нативного приложения, когда стоит выбор поставить x86-сервер или более дешёвый ARM-сервер с транслятором.
А по поводу разницы эффективности в Linux VM под macOS и WSL, у вас нет идей, что к этому приводит? Разница самих процессоров?
Armmaster Автор
12.09.2021 00:50Вопрос про разницу не очень понял, там вроде результаты достаточно похожи. Или имеется ввиду, что большие различия на Mac Mini и Huawei MateBook E ? Так там 2 разных процессора стоят совершенно, понятно что цифры разные.
Viknet
12.09.2021 01:00Я про вот эту разницу.
Exagear efficiency (Geekbench, SPEC2017int, SPEC2017fp) под Linux VM на M1:
82.4%, 91.6%, 86.1%
Под WSL (тут же тестируется WSL2, который по факту тот же Linux VM?) на Qualcomm:
70.9%, 81.9%, 74.3%Всё-таки больше 10% дополнительного провала производительности при переходе на Windows-хост.
Armmaster Автор
12.09.2021 01:07А, ну так там есть в тексте по этому поводу следующая ремарка:
В запусках ExaGear в окружении WSL обнаружилась проблема, что WSL не предоставляет используемые нами для профилирования таймеры, из-за чего не включается режим дооптимизации кода и ExaGear не демонстрирует максимальные цифры производительности. Потери скорости в таком случае можно оценить в 10-20% в зависимости от бенчмарка
Т.е. у нас под WSL не работает последний уровень оптимизации из-за этого. А так цифры должны быть примерно такими же, как и на M1, конечно же.
Viknet
12.09.2021 01:31Вот этот момент проигнорировал, потому что не понял, что за дооптимизация.
Можете чуть подробнее рассказать, про эту функциональность? Это оффлайн-режим вроде PGO, отрабатывыающий между запусками, или перекомпиляция (перетрансляция) кусков кода "на лету" по рантайм-метрикам?Armmaster Автор
12.09.2021 02:15Это второе. На основе профиля выделяются горячие участки кода и они перекомпилируются с помощью самого последнего уровня оптимизатора с максимальными настройками.
WojciehRu
24.09.2021 18:10+1А давно exagear продали huawei? Толком нигде информации нет, что с eltech?
vovche
24.09.2021 18:10Макбук можно в любом городе купить, microsoft эмуляцию можно даже на raspberry pi 4 запустить.
Как дела с доступностью вашей технологии для конечного пользователя?
Armmaster Автор
24.09.2021 18:11https://mirrors.huaweicloud.com/kunpeng/archive/ExaGear/
Правда это старая версия.
ZhymabekRoman
27.09.2021 16:53@Armmasterприветсвую! Будет ли Huawei развивать мобильную ветку Exagear? Т.е. Exagear Windows/Exagear RPG/Exagear Strategy? Сейчас опенсоурсное комьюнити пытется создать эмулятор x86 (к примеру box86/box64), но работают они очень сыро, и в целом принцип работы другой. Очень хотелось бы увидеть реально стоящии эмулятор Windows среды на Android.
Gumanoid
27.09.2021 18:00ArmV8.7, которая официально была принята и опубликована только осенью 2020-го года. Причём существенная часть этого расширения является ничем иным, как аппаратной поддержкой двоичной трансляции, призванной упростить трансляцию некоторых операций из архитектуры x86
Не подскажите, какие именно это расширения? Enhanced Translation Synchronization?
vesper-bot
Интересно, что в тесте Ray tracing ARM/MacOS обходит ARM/Linux примерно на 24%. При этом в абсолютных "попугаях" Rosetta и Exagear почти равны. Откуда такая разница?
Armmaster Автор
Ответ на второй вопрос проще - ExaGear лучше оптимизирует код, поэтому итоговая цифра оказывается близкой к Rosetta 2. А вот на первый вопрос точно ответить сложно, для этого надо существенно глубже залезть в MacOSовскую версию и разобраться, что там компилятор наделал. Скорее всего различие возникло из-за различия стандартных библиотек на MacOs и Linux, но это гипотеза