Какой компилятор даст самый быстрый код на x86 (i386)

Я имел ввиду gfortran, но судя по всему в текущем топике это не имеет какого либо значения.

В текущем топике спрашивается про c/c++ а не про fortan

А что ты предлагаешь, магическим образом обойти транслятор? Не смеши меня.

Причём тут обойти? Ты понимаешь, что транслятор и реальное железо обладает разными свойствами? Дак мало того, что у тебя не просто транслятор - у тебя транслятор и ещё под ним другая архитектура уже со своими свойствами.

Таким образом «самый быстрый код» на х86 далеко не означает, что он будет оставаться быстрым проходя через транслятор. А может вообще его ломать.

Поэтому я тебе и сообщаю, что твой случай не в том, что тебе нужен быстрый код под х86, а совершенно в другом. Тебе нужно то, что наиболее оптимально ляжет и на твой транслятор и на то, что он там сгенерирует.

Поэтому, очевидно, никто тебе ответ не даст. Никакая информация об оптимальности на нативном железе тебе не поможет. К тому же - i386 - это мёртвое говно, которое в мире х86 никому ненужно. И никто никакой оптимальности там не добивается. Это мёртвый таргет, осознай это.

С этим проблем нет, sse конвертируется в neon почти без потерь, сам сравнивал и убедился. Остались проблемы самих компиляторов. Не надо меня тут учить.

Я сомневаюсь, что ты там что-то знаешь. Потому как совершенно левый человек сообщил о том, что тебе нужно. И оказалось, что ты в критериях указал совершенно не то, что тебе нужно. И ещё пытался обманывать пацанов.

Поэтому, единственный твой вариант - это перестать играть в идиота и сказать что тебе нужно. Авось кто-то имел дело с этими трансляторами.

Либо по крайней мере тебя научат не компилировать на мобилке. Хотя это идиотизм какой-то. В чём проблема найти нормальное железо и собрать? Зачем ты пишешь эти мазы? Очевидно, что даже если человек знает как тебе помочь - он не будет этого делать. Потому как для него твои мазы - идиотизм. И помочь тебе нужна лишь потому, что у тебя проблема далеко не там, где её наличие ты декларируешь.

На какой к чёрту мобилке, я компилирую на мк

пк*

С этим проблем нет, sse конвертируется в neon почти без потерь, сам сравнивал и убедился. Остались проблемы самих компиляторов. Не надо меня тут учить.

Ты ничего не знаешь ни про sse, ни про компиляторы, ни про матчасть, ни про что-либо ещё. Убедился он. Со мною такая херня не прокатит, потому как по определению я знаю, а не ты. И доказать я могу это кода угодно и это уже доказано мною тут тысячи раз.

Поэтому ненужно передо мною играть в эту херню нелепую. Я учу потому, что могу. В отличии от тебя, который меня ничему научить не может. Запомни это и никогда подобной чуши мне не пиши.

Ты вообще читаешь, что тебе пишут?

Допустим, одну и ту же работу можно выполнить на x86 либо блоком инструкций xxxx, либо блоком инструкций yyyy. Причём на целевой микроархитектуре xxxx выполняется за 5 тактов, а yyyy — за 7. Компилятор выберет xxxx, потому что ожидается, что это быстрее. Теперь, допустим, твой транслятор вынужден реализовывать обработку инструкций так, что xxxx он выполнит за 27 тактов, а yyyy — за 23. Тогда оптимальный для x86 вариант будет выполняться в трансляторе дольше, чем неоптимальный. Капиш?

я компилирую на мк

Вот это было бы крутым достижением.

Мне и не нужно это знать, я на практике проверял, и своими глазами видел разницу.

Оскорблять меня необязательно, тем более, что я компилирую не на мобилке

У тебя течёт методичка. «модем, 2гига памяти, память не поменять, ноутбук». Очевидно, что никакого ПК у тебя нет.

Осталось понять почему и зачем ты врёшь. Хотя мне лень с этим разбираться. Я вижу тему - захочу. Начинаю писать, а потом вижу, что у нас в теме мамкин конспиратор. Т.е. ты уже меня подставил. Но даже так я тебе сообщил достаточно.

И ты вместо ответа начал что-то там из себя строить. Лишь отвечай нормально, либо опять меня затриггерит. Не провоцируй меня.

Рофлить мне некогда, я с вами говорю нормально, но вы сопротивляетесь. Да делайте что хотите, я лучше на reddit спрошу чем на этой помойке

Не, ну правда, нах$€ компилировать на помёте? https://www.scaleway.com/en/pricing/

$0.5 то у тебя есть на час работы 16 ядер и 96 гигов оперативы?

GP-BM1-L 1× AMD EPYC 7281 16C 32T - 2.1 GHz 96 Гбайт оперативы

Рекомендую. Никаких скрытых платежей за траффик. Выкачивай в виртуалку из Инета, а не с лаптопа лей. Если будешь лить с лаптопа - пожми тар через xz -T4 -8

И поставь свежую Debian 10, gcc-9, llvm-9

Всё в офф репах есть, собирай - не хочу

Оскорблять меня необязательно

И где ты там оскорбление разглядел, интересно?

Поверь, на редите ещё быстрее вылетишь, там по таким чёртовым делам никто не заморачивается

Всё в офф репах есть

Самый свежак тут https://apt.llvm.org

Мне не надо ссылок и объяснений для дурачка, я вообще не просил вас ни про какой vps мне рассказывать, всё это и без вас мне известно.

Не без этого, но и в офф репах дебиана тоже всё это же есть, иногда проще всякие unstable подключить)

Вопрос стоял: ЛУЧШИЙ КОМПИЛЯТОР ДЛЯ I386. ВСЁ!

Понимаешь, домохозяйка тоже видит разницу между красной машиной и зелёной. Но значит ли это что-то? Нет. Ненужно себя в чём-то убеждать.

А, ну в целом я понимаю откуда вы такие взялись. Ты наверное сборщик-старовер, работаешь по заветам предков - увидел sse-инструкцию - значит векторизация есть, значит профит есть.

Ну это прям 1в1 мой пример про красную/зелёную машинку. Ты там авось ещё и s считаешь за sse.

Поэтому я тебе повторяю. Делать какие-то выводы на базе аналитики может только человек с достаточными познаниями, которых у тебя нет. Да и мало у кого они есть. Даже я вообще нихрена не знаю про arm и то настолько оптимально это говно транслируется.

Поэтому в данных условиях есть только один вариант - тестировать. Получать объективные метрики и их сравнивать. Другого пути у тебя нет.

Мне виднее.

Ты похоже не понимаешь нормального тона. Тестировал я уже 30 раз, нехер мне тут умничать

Лучший компилятор для 386 - это gcc по производительности результирующего бинарника, и clang/llvm по скорости компиляции/отчётам по утечкам/ошибкам и прочему. Т.е. для разработчиков предпочтителен LLVM, для ментейнеров и универсальности - GCC

но и в офф репах дебиана тоже всё это же есть

Нету. Да и хрупкий этот дебиан, лучше докер сразу навернуть.

Ещё раз. Нету такого понятия как «лучший компилятор». Лучший в целом - это gcc, но i386 мёртвый таргет и всем на него насрать. Но это не значит, что в каждом конкретном случае gcc выиграет без дополнительного тюнинга. У него достаточно консервативная конфигурация, в отличии от того же llvm.

Поэтому, очевидно, что простой вопрос на это «собери и сравни». На что ты уже начал мазаться «да я не могу - у меня два гига». И вот уже на это тебе отвечают, как решить проблему двух гигов.

А про icc почему никто даже не упомянул? Он под i386 работает на треть быстрее.

clang/llvm по скорости компиляции

Тебя обманула пропаганда. Ещё со времён середины третей ветке clang/llvm деградировал до уровня ниже gcc. После gcc9 не слабо так оптимизировали, появилась lto-сборка, которая дала ещё больше буста.

Сейчас gcc в среднем в 2 раза быстрее шланга. За счёт fwhole-program и соответствующих ему оптимизаций - более чем в 2 раза.

отчётам по утечкам/ошибкам и прочему.

Что за «отчёты по утечкам» я не знаю. По ошибкам clang всегда был в говне, особенно сейчас. Тут тебя так же обманула пропаганда.

У шланга остались пару десятков случаев уровня «пропустил template», которые перепащивают из методички в методичку. В реальности же ошибки в clang говно.

Ни разу я не смог разобраться в ошибке по асисту шланга. Всегда приходится собирать gcc и смотреть.

Т.е. для разработчиков предпочтителен LLVM

Нет, для разработчиков llvm - мусор. Шланг интересен только как языковые сервисы для C/C++. Как компилятор - он говно. Полное.

А про icc почему никто даже не упомянул? Он под i386 работает на треть быстрее.

Потому как icc - это говно. А то, как он там работает под i386 - никого не волнует. Этот таргет никому, кроме музеев, ненужен.

icc не умеет ни в си, ни в С++. Кодоген у icc говно. Как компилятор он говно. Ещё хуже шланга. Быстрее он только на кейсах «считалку писал студент». Он имеет всякие эвристики для выделения запартных паттернов и трансформации их в нормальный код, либо в библиотечные вызовы.

За пределами запарты в реальных кейсах и на нормальном коде - это не работает. Самое интересное, что я когда-то тоже надеялся на чудо, что вот там то будет нормальный шедулер, но нет - он хуже гццешного.

Такое ощущение, что те, кто занимается этим компилятором в интеле - вообще далеко от их микроархитектур и особенностей железа. И те люди, что в интеле работают с гцц - куда лучше.

Потому как иначе объяснить это невозможно.

Он под i386 работает на треть быстрее.

Публично доступные источники не подтверждают это высказывание. Производительность сгенерированного ICC кода находится примерно на уровне кода, генерируемого GCC. Иногда быстрее, иногда медленнее.

Спасибо за ответы, это и есть то что я хотел услышать

В конце концов, не я же сижу на линуксе 20 лет, чтобы знать всё про эти компиляторы

Спасибо, что подтвердил факт своего наглого вранья. :-D

Правда, это не то, что я хотел услышать.

Пять минут на поиск в гугле. Пять. Минут. Это всё, что требуется, чтобы найти ответы на эти вопросы.

8 часов суммарно я потратил на поиск в гугле и нашёл везде разные отзывы

Опять обманываешь?

Мой дух сломить не удасться на пути к цели твоими оскорблениями

Мой дух сломить не удасться

Его никто не ломает кроме тебя. Тебе тут наоборот помогают, а ты только сквернословишь. Ну, не считая Царя. Он особенный, он не в счёт. Остальные тебе много по делу советовали. Именно про решение проблем, а не тупо ответ на бессмысленный вопрос.

твоими оскорблениями

Если ты пишешь заведомую ложь о том, что icc даёт на 30% более быстрый код, сказать тебе, что ты лжёшь — не оскорбление.

Что было написано в гугле то и говорю

ifort

А весело у вас тут.

Уже нет

Потому что это самые лучшие процессоры в плане уязвимостей. Не зря же их используют на шатлах

Не напомнишь, где именно? В DPS там все 5 компов - IBM AP-101S.

Однако где-то слышал, что где-то в MEDS i386 был. Ну в принципе оно и верно, вряд-ли древний ибм осилил бы такую красивую графику.

Вроде в самих аппаратах, то есть блоки управления самим шатлом. Но где «купил» не помню…

Не, ты чё-то попутал, или опыта у тебя мало.

Коротко говоря, идут они в ногу. Завтра даже вышлю тебе бенчи сборки quickjs с GCC9 vs Clang9, там как раз есть lto у quickJS

Medium: GCC vs CLANG

На 4pda ТС как-то нафлудил себе репутацию супер-специалиста

Там это сделать крайне несложно :)

Не, ты чё-то попутал, или опыта у тебя мало.

Попутал ты. И опыта нет у тебя.

Коротко говоря, идут они в ногу.

В твоих фантазиях.

Завтра даже вышлю тебе бенчи сборки quickjs с GCC9 vs Clang9, там как раз есть lto у quickJS

У шланга нету полноценного lto. Методичка уже потекла. Ну попытайся.