LINUX.ORG.RU

компилятор с++ совместимый по ключам и некоторым библиотекам с gcc строящий более оптимальный по скорости исполнеия код

 , ,


1

4

Здравствуйте ! Где найти компилятор с++, совместимый по ключам и некоторым библиотекам с gcc, строящий более оптимальный по скорости исполнеия код ? gcc создавался долго и хаотично разными разработчиками, часто далекими от научных подходов и не знающих их.


gcc создавался долго и хаотично разными разработчиками, часто далекими от научных подходов и не знающих их.

Фигаса заявочка, тогда сам пиши, есть clang есть проприетарные компиляторы от интел дохрена их если нужно. Но одно советую точно не стоит обвинять разработчиков в том что они не используют «научные» подходы. Причём тут вообще наука? Оптимизация и научный подход порой вообще несовместимы. gcc по части оптимизации как тузик грелку рвёт любые открытые компиляторы в большинстве случаев

Deleted
()
Ответ на: комментарий от Deleted

«Причём тут вообще наука? Оптимизация и научный подход порой вообще несовместимы.» Вы очень сильно ошибаетесь .

ustas1
() автор топика
Ответ на: комментарий от ustas1

Хорошо, тогда нужно привести

  • 1 - Тестируемый иходный код
  • 2 - Его сборку с gcc и тесты затрат процессорного времени на вычисления
  • 3 - Его сборку с иным компилятором с аналогичными тестами
  • 4 - Сравнение подходов конкретных оптимизаций

Или хотя бы сказать что «сборка от компилятора foo работает быстрее чем от компилятора bar, но у меня есть код специфичный для bar где взять компилятор fooX который будет иметь совместимость с bar, но с оптимизациями как foo»

Deleted
()

gcc создавался долго и хаотично разными разработчиками, часто далекими от научных подходов и не знающих их

Возьми Open64, его предок MIPSPro создавался крутыми остепененными чуваками

annulen ★★★★★
()
Ответ на: комментарий от Deleted

«Тестируемый иходный код» http://wwwlehre.dhbw-stuttgart.de/~sschulz/WORK/E_DOWNLOAD/V_2.3/E.tgz

от автора E prover - «his file contains notes on potential porting problems for E.

* Compilation with other compilers E is tested during development with gcc and clang on Linux and Mac OS X. If you do not have access to gcc, but have a proprietary C99 compiler, you need to adjust the build process as follows:

- set these variables in Makefile.vars: - CC to your C compiler (usually cc) - CFLAGS to the proper options for your compiler - MAKEDEPEND to use makedepend instead of the compiler - execute ./configure - execute ./make

* Since some of the conceptual set and bag operations are indeed implemented as set and bag operations, the order in which some operations are performed may depend on the addresses your C library hands out for malloc()ed blocks. This will effect the exact behaviour of the prover on a per run basis.»

ustas1
() автор топика

Clang и Intel-овский компилятор уже советовали, у меня ещё два ответа, оба скорее всего не понравятся.

  1. В духе товарища Сталина - «Других компиляторов у меня нет».
  2. Такой компилятор - программист. Берёт программу, профилирует, находит узкое место и переписывает на совместимом с C++ по ABI ассемблере!
tim239 ★★
()
Ответ на: комментарий от ustas1

Код там не адовый, раздуплить можно, malloc/calloc/realloc дохрена тут непооптимизируешь, В любом случае чуда не будет либо

  • 1 - пересобрать со всеми компиляторами что сможешь найти включая платные и всё такое и выбрать наилучший.
  • 2 - профайлер в зубы искать узкие места после варианта 1 или применить вариант 1 после варианта 2.

В любом случае это надо встать принести баклашку воды и поставить к столу. Затем идти на кухню взять тройку кружек/сахар/кофе и захватить с собой чайник электрический принести всё это к столу (не забыть пару киллограм печенья) Ну и далее отходить только посцать да покурить (КУРЕНИЕ ВРЕДИТ ВАШЕМУ ЗДОРОВЬЮ!) скурпулёзно изучая код на предмет улучшений потребляя литры чая и кофе не отходя от кассы

Deleted
()
Ответ на: комментарий от KennyMinigun

Тут нарушения посерьёзнее копролалии.

anonymous
()
Ответ на: комментарий от ustas1

Видимо это всё-таки какой-то неумелый троллинг. Я прочёл статейку по ссылке, там автор запускает бенчмарк на основе SMT-solver'а, один и тот же код с одинаковыми ключами оптимизации и одним и тем же компилятором но на разных архитектурах:

Both systems ran Z3 4.8.1, compiled by me using Clang with the same optimization settings.

На айфоне получилось чуть быстрее чем на i7, автор подумал почему так и решил что благодаря тому что

the A12 chip has a gigantic, low latency L2 cache

Где неизвестные чудо-компиляторы в этой истории? Их нет.

tim239 ★★
()
Ответ на: комментарий от RazrFalcon

Отличный вброс. У меня аж бурление началось и желание написать ответ появилось. Не надо бана. По крайней мере, сразу.

i-rinat ★★★★★
()
Ответ на: комментарий от ustas1

При чем тут вообще SMT солверы? Там ничего никто не доказывал в отношении самого компилятора и процесса компилирования, там просто сравнивалась скорость солвера на разных процессорах. Если тебе нужен компилятор с доказанной корректностью, вот он - http://compcert.inria.fr/compcert-C.html

What sets CompCert C apart from any other production compiler, is that it is formally verified, using machine-assisted mathematical proofs, to be exempt from miscompilation issues.

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

SZT ★★★★★
()
Последнее исправление: SZT (всего исправлений: 1)
Ответ на: комментарий от tim239

Clang и Intel-овский компилятор уже советовали, у меня ещё два ответа, оба скорее всего не понравятся.

Только в твоих фантазиях они генерируют «более оптимальный по скорости исполнеия код».

C++ по ABI ассемблере!

Такого нет. Попытайся ещё раз.

anonymous
()

gcc создавался долго и хаотично разными разработчиками, часто далекими от научных подходов и не знающих их.

Вообще-то, почти все, что используется в реальном мире создавалось способами далекими от научного подхода, иначе оно с реальностью не стыкуется. Плод науки - дисеры, от яйцеголовых профессоров, оторванные от реальности, а также Хаскель (да и вся фукнциональщина) созданный математиками для математиков, который хоть как-то работает на искусственных примерах, а в реальных задачах никак, даже с костылями.

Научный подход и работающий продукт два нестыкующихся понятия. Первый ориентируется на искусственные ограничения и непонятно какие критерии правильности (широкий простор для субъективности и подгонки результата под желаемый ответ, потому что даже «наша теория подтверждается экспериментом» давно поддается фальсификации, ибо результат эксперимента уже давно не прямые наблюдения, а результат обработки экспериментальных данных с широкими возможностями притягивания за уши). Второй ориентируется на работоспособность в реальной жизни и удобство использования (люди пользуются - значит подход работает, даже если люди пользуются тремя разными продуктами, основанными на взаимоисключающихся методах). Вообще, основная причина почему люди чем-то пользуются - «потому что это работает». А «основано на научных методах» или в 90-х любили «рассчитано на компьютере» - это в чистом виде маркетинг. Было бы что продать, а подходящая научная теория найдется. И наоборот, неважно на чем основан продукт, но если он не работает - это никому не нужно.

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

P.S. IMHO в «науке» 95% шарлатаны, демагоги и просто балаболы, ориентированные на освоение грантов, а результаты подтягиваются под нужный «ответ» и нужны только для оправдания освоения гранта.

anonymous
()

gcc создавался долго и хаотично разными разработчиками, часто далекими от научных подходов и не знающих их.

Linux тоже. И он теперь в науке, а проприетарные научные Unix’ы – на помойке. Лол.

EXL ★★★★★
()

PGI community edition (сейчас принадлежит nvidia) попробуй. По условиям лицензии ты должен использовать определённую версию его не больше года после её выхода. То есть должен будешь обновляться.

Clang в некоторых случаях генерит более быстрый код чем GCC. Всё зависит от задачи и её реализации. Бери и тестируй на своём коде (а ты как хотел?).

Ещё есть мнение, реализация библиотеки math для GCC (libm) очень «медленная» на функции степеней и тригонометрии, поэтому можешь попробовать прикрутить какой-нибудь openlibm.

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 1)

Странное требование.

invy ★★★★★
()
Ответ на: комментарий от EXL

Тссс...

Только не показывайте «клиенту» https://www.top500.org/statistics/list/, его порвёт на оверлеи... =))) Там, если выбрать по Operating System Family, то кроме Linux во всём списке top500 ничего и не найдётся больше. Раньше там и винды были и SUN Grid и ещё чего-то, не помню уже...

Интересно, чем же кроме «науки» занимаются эти пробкотроны, жрущие мегаватты энергии? =)))

Moisha_Liberman ★★
()

Например Green Hills (https://www.ghs.com/). По ключам совместимости правда нет. И да, денег стоит.

vromanov ★★★
()

сколько раз говорил, сделайте вход на лор только по паспорту

anonymous
()

Шутники в треде забыли, что Царь не спрашивает - скорее он сам всем расскажет, какой же компилятор самый правильный.

А так - оптимизации со стороны программиста важнее оптимизаций со стороны компилятора.

По совместимости - всё будет совместимо, если портативно будешь писать сам. Не используй gcc-измы, glibc-измы, msvc-измы и прочие аневризмы, и всё будет хорошо. Только я вангую, что ты и не знаешь, что это.

Bfgeshka ★★★★★
()

Давай для начала ты несовместимый с gcc такой компилятор покажешь. Что бы он генерировал более эффективный по скорости код, желательно не на синтетическом примере.

Потом мы твой бенч прогоним под pgo, и пересоберём, ладно?

pon4ik ★★★★★
()

Пациент не указал платформу, не вижу указания x86, а стало быть всякие Keil и IAR на каких-то МК могут выдать чуть более оптимальный код. Версия C++ не указана, а там может и компилятор для Эльбрус сгодится )))

Мне кажется, на фоне того что если бы AMD вкладывался в GCC например, а Intel не стал, то учитывая как много собирается GCC, это бы дало плохой результат для Intel, и вынудило таки дотянуть GCC куда надо. Возможно так уже и произошло, но я не очень уверен, может мне кажется это.

I-Love-Microsoft ★★★★★
()

gcc создавался долго и хаотично разными разработчиками, часто далекими от научных подходов и не знающих их.

Это правда. Однако и сам C++ достаточно далек от научных подходов. И ещё дальше от научных подходов программисты, которые пишут дремучий говнокод. Мусор на входе — мусор на выходе. Это так работает.

Crocodoom ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.