The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз компилятора PCC 1.0.0, распространяемого под лицензией BSD

03.04.2011 02:32

Андрес Магнуссон (Anders Magnusson) представил первый стабильный релиз компилятора PCC 1.0.0 (Portable C Compiler), развиваемого с целью создания альтернативы Си-компилятора из состава GCC, распространяемой под лицензией BSD. PCC достиг стабильного состояния при работе на платформах i386 и amd64 в различных ОС, включая BSD-системы, большинство Linux-дистрибутивов, а также Microsoft Windows. Поддержка остальных аппаратных платформ еще недостаточно отлажена и может содержать ошибки и недоработки. Следом за версией 1.0.0 в недалёком будущем будет выпущено несколько корректирующих релизов, после чего ожидается версия 1.1 с реализацией более серьезных изменений.

На данный момент PCC может быть использован для сборки большинства составляющих базовой системы FreeBSD, NetBSD и OpenBSD. PCC полностью совместим со стандартом C99 и частично совместим с GCC. Процесс компиляции осуществляется в несколько раз быстрее, чем в GCC, при приемлемом уровне кода на выходе. Например, сборка тестового комплекта ByteBench, выполненная при помощи gcc 4.1.3 (режим оптимизации "-O2") оказалась в большинстве тестов лишь на несколько процентов быстрее сборки с использованием PCC (исключение составил тест dhry2reg, при котором PCC отстал почти в два раза и тест hanoi, при котором отставание было на уровне 30%).

Компилятор PCC основан на оригинальном компиляторе Portable C Compiler Стива С. Джонсона, который был написан в конце 70-ых годов прошлого века. Хотя большая часть компилятора была переписана, некоторые составляющие остались. Portable C Compiler появился в Unix Version 7, в качестве замены компилятору DMR (оригинальный компилятор, созданный Дэнисом Ритчи) в выпусках System V и BSD 4.x. Некоторые моменты истории Portable C Compiler описаны в статьях История UNIX до Беркли: Эволюция UNIX: 1975-1984 и Эволюция C.

Около 50% кода фронтэнда и 80% кода бэкенда современной версии PCC было переписано. Большинство кода написано Андресом Магнуссоном, исключая часть анализа потоков данных и SSA-преобразований, написанные Питером Джонсоном (Peter A Jonsson). Порт для архитектуры MIPS написан в рамках студенческого проекта Технологического университета Лулео (LUT).

Для стимулирования обеспечения возможности сборки Linux-ядра при помощи PCC представлена инициатива "book bounty" (The Linux/pcc Bounty Book Bundle), в рамках которой организовано соревнование с простым правилом "необходимо первым собрать текущее Linux-ядро, используя pcc", победитель будет награждён шестью книгами от No Starch Press и O'Reilly Media.

Размер архива с исходными текстами PCC 1.0.0 занимает менее мегабайта. Финансирование доведения PCC до первого стабильного релиза предоставлено проектом BSD Fund. Разработчики будут благодарны за тестирование PCC. Со списком планов по развитию PCC можно познакомиться на странице Road map. Желающие принять участие в разработке PCC, могут обратиться на email dexter at bsdfund dot org.

  1. Главная ссылка к новости (http://marc.info/?l=pcc-list&m...)
  2. OpenNews: Разработчики компилятора PCC начали процесс подготовки релиза 1.0
  3. OpenNews: В компиляторе PCC обеспечена возможность сборки FreeBSD
  4. OpenNews: Свободный компилятор PCC доведен до состояния, позволяющего собрать ядро OpenBSD
  5. OpenNews: В компиляторе PCC появилась поддержка архитектуры AMD64
  6. OpenNews: В состав NetBSD и OpenBSD включен Си компилятор PCC с лицензией BSD
Автор новости: a
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/30110-Pcc
Ключевые слова: Pcc, compile, gcc
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (82) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 10:23, 03/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Хороший компилятор. гентушники одобряют?
     
     
  • 2.2, dimqua (ok), 10:44, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +16 +/
    Когда будет быстрее GCC - одобрим.
     
     
  • 3.11, Аноним (-), 11:43, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >Процесс компиляции осуществляется в несколько раз быстрее, чем в GCC, при приемлемом уровне кода на выходе.

    В новости же написано.

     
     
  • 4.15, dimqua (ok), 12:09, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Я имел ввиду результат на выходе.
     
  • 4.76, anonymous (??), 15:23, 06/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>Процесс компиляции осуществляется в несколько раз быстрее, чем в GCC, при приемлемом уровне кода на выходе.
    > В новости же написано.

    серия 4.1? не смешите мои полудохлые тапочки. они бы ещё более древний GCC взяли, чтобы получше результаты вышли.

    советую прчитать changelogs на новые gcc. про межпроцедурную и межмодульную оптимизацию хотя бы. для начала. пцц хорош для сборки мелкопроектов, где производительность, в принципе, пофигу.

    я не к тому, что пцц не нужен — нужен. только не надо его с гцц сравнивать: разного калибра игроки.

     
  • 3.23, User294 (ok), 13:32, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Когда будет быстрее GCC - одобрим.

    Когда он сможет мне сгенерить код под ARM* и MIPS32 не хуже GCC, тогда и я подумаю...

     
     
  • 4.37, z (??), 15:35, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +11 +/
    >Когда он сможет мне сгенерить код под ARM* и MIPS32 не хуже GCC, тогда и я подумаю...

    Как это "ПОДУМАЮ"? Погоду не порть людям Юзер. А как же святая вера в ГПЛ? У PCC не правильная лицензия, тут и думать нечего. Оно недостойно праведных бубунтоводов.

     
     
  • 5.58, User294 (ok), 01:52, 04/04/2011 [^] [^^] [^^^] [ответить]  
  • –11 +/
    На самом деле, зная бздунов я предполагаю что мне повезет, если я увижу нечто похожее на упомянутое хотя-бы к моменту выхода на пенсию :P.
     
     
  • 6.65, Свидетель Столлмана (?), 04:50, 04/04/2011 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Сама мысль греховна сын мой! :( Сначала ты подумаешь про компилятор демонический, а потом и греховные мысли об установке BSD появятся. А там и до проепритарщины докатишься, и сгинет душа твоя в геенне огненной.
     
     
  • 7.71, User294 (ok), 09:54, 05/04/2011 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > и до проепритарщины докатишься,

    Всегда подозревал что бздуны - латентные проприетарщики, а тут прямо официальное подтверждение :)


     
     
  • 8.72, Свидетель Столлмана (?), 10:59, 05/04/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Все верно Ты один из самых способных, среди уверовавших в светлый образ чистой ... текст свёрнут, показать
     
     
  • 9.74, User294 (ok), 20:21, 05/04/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если его величество эволюция так распорядится - значит будет так Те кто вымер -... текст свёрнут, показать
     
  • 2.3, анон (?), 10:46, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Нет. В лучшем случае им можно собрать только около 40% что есть в портежах. Да что там говорить?
    > На данный момент PCC может быть использован для сборки большинства составляющих базовой системы FreeBSD, NetBSD и OpenBSD.
    > большинства составляющих

    Тоесть он даже не может собрать всё что есть в портах тех ОС для которых он пишется.

     
     
  • 3.43, Аноним (-), 16:06, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Нет. В лучшем случае им можно собрать только около 40% что есть
    > в портежах. Да что там говорить?
    >> На данный момент PCC может быть использован для сборки большинства составляющих базовой системы FreeBSD, NetBSD и OpenBSD.
    >> большинства составляющих
    > Тоесть он даже не может собрать всё что есть в портах тех
    > ОС для которых он пишется.

    О портах в статье речь не идет, он не может собрать всю базовую систему, т.е. мир


     
     
  • 4.45, я (?), 16:53, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > ...он *не может* собрать всю базовую систему, т.е. мир.

    Не пудрите мозги людям. Как раз базовую систему (мир) он собирает. Базовая система это ядро и минимальное окружение. В /usr/src кроме ядра разные утили, bind, ftpd, sshd и т. д. А в портах лежит прикладной софт к которому разработчики BSD уже никакого прямого отношения не имеют.

     
  • 2.57, AMD Man (?), 01:48, 04/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А что у нас есть ещё с полной поддержкой C99?
    GCC до сих пор не сподобился...
    А уже новый стандарт языка на носу...
     
     
  • 3.73, pavlinux (ok), 13:53, 05/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Можно примеры кода C99 не понимаемого GCC?!

    Вот эту табличку не надо http://gcc.gnu.org/gcc-4.6/c99status.html
    Код реальный, плиз.

     
     
  • 4.77, anonymous (??), 15:25, 06/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Можно примеры кода C99 не понимаемого GCC?!
    > Вот эту табличку не надо http://gcc.gnu.org/gcc-4.6/c99status.html
    > Код реальный, плиз.

    в кои-то веки соглашусть с павлином. то ли я деградирую, то ли павлин умнеет...

     

  • 1.4, gegMOPO4 (ok), 11:03, 03/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Альтернативный свободный компилятор — это, конечно, хорошо, но более серьёзных тестов, чем сделанной почти год назад оценочной прикидки на небольшой выборке из ByteBench (в нём десятка два тестов), нет?
     
     
  • 2.24, xl32 (ok), 13:34, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Может, тесты и есть. Но они не собираются :-D
     

  • 1.5, Sinot (ok), 11:04, 03/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Процесс компиляции осуществляется в несколько раз быстрее, чем в GCC, при приемлемом уровне кода на выходе.

    То есть PCC быстрее, а дальше

    > Например, сборка тестового комплекта ByteBench, выполненная при помощи gcc 4.1.3 (режим оптимизации "-O2") оказалась в большинстве тестов лишь на несколько процентов быстрее сборки с использованием PCC (исключение составил тест dhry2reg, при котором PCC отстал почти в два раза и тест hanoi, при котором отставание было на уровне 30%).

    То есть PCC медленнее. о_О Поясните пожалуйста где ошибка? Или PCC медленнее только с этим пакетом?

     
     
  • 2.10, Аноним (-), 11:33, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    быстрее при сборке, код немного медленнее на выходе
     
  • 2.29, Аноним (-), 13:49, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Здесь работает простой принцип: чем дольше запрягаешь - тем быстрее едешь
     

  • 1.6, x0r (??), 11:17, 03/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    уже есть clang.  этот по сравнению с clang - совсем не серьезно, и не понятно когда будет готов
     
     
  • 2.7, mapron (ok), 11:20, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Больше компиляторов, хороших и разных!
    Один продукт в одной нише - отсутствие конкуренции - застой. Ну уж нет.
     
     
  • 3.9, Аноним (-), 11:22, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >отсутствие конкуренции

    её и так не будет. PCC не конкурент никак.

     
  • 3.12, Аноним (-), 11:59, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Типичная позиция красноглазика не понимающего зачем пишут программы сложнее hello world.
     
     
  • 4.22, vle (ok), 13:15, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Типичная позиция красноглазика не понимающего зачем пишут программы сложнее hello world.

    Это ты красноглазик, не понимающий, в чем ценность маленьких
    и хорошо спроектированных программ, которые хорошо выполняют
    свою функцию. Именно такими программами
    и создавалась история UNIX.

    Знаешь, есть такая штука -- отношение
    ценность/затраченные_усилия_по_написанию_и_поддержке_кода.
    Так вот у pcc этот показатель очень высок.

     
     
     
    Часть нити удалена модератором

  • 6.32, Аноним (-), 14:11, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >разрабатывается с 70-ых годов прошлого века.

    http://pcc.ludd.ltu.se/pcc_history/
    It was publicly announced to the NetBSD community on September 14, 2007. Shortly later it was imported to the OpenBSD, NetBSD, and pkgsrc source trees.
    Most stuff is written by Anders Magnusson

     

  • 1.8, Аноним (-), 11:21, 03/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >выполненная при помощи gcc 4.1.3

    а с 2.95 сравнить не хотят? на дворе 2011 год, 4.6.0 вышел.

    В целом оно не нужно, есть clang(llvm)

     
     
  • 2.13, d (??), 12:00, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • –3 +/
    так ведь бсдшники всегда с 1913 годом сравнивают
     
  • 2.14, онином (?), 12:08, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Как сказать, в той же FreeBSD вероятно теперь gcc отправят в систему портов из базовой системы, как это когда-то произошло с Perl. Базовая система быстрее будет собираться благодаря этому. А исходный код BSD-систем скорее всего начнут оптимизировать под pcc. Так что для BSD-систем плюсы есть, для остальных они пока сомнительны.
     
     
  • 3.17, arcade (ok), 12:16, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Исходный код FreeBSD написан на ISO-стандартном языке. Коммит gcc'измов запрещён. Оптимизировать под "ещё один компилятор" никто не будет.
     
     
  • 4.18, онином (?), 12:21, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Коммит gcc'измов запрещён.

    Не знал. Но в любом случае, на компиляцию самого gcc уходит слишком много времени при сборке системы. И если мне не изменяет память gcc два раза при этом процессе собирается.

     
     
  • 5.56, rico (ok), 23:48, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    три
     
  • 4.31, User294 (ok), 14:05, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Исходный код FreeBSD написан на ISO-стандартном языке. Коммит gcc'измов запрещён. Оптимизировать
    > под "ещё один компилятор" никто не будет.

    Как обычно, в теории все круто а на практике - ну вы в курсе, да? Система без софта под нее - и даром никому не нужна. Осталось только убедить авторов прикладух не юзать gcc'измы, и дело в шляпе :)

     
     
  • 5.33, iZEN (ok), 14:31, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Исходный код FreeBSD написан на ISO-стандартном языке. Коммит gcc'измов запрещён. Оптимизировать
    >> под "ещё один компилятор" никто не будет.
    > Как обычно, в теории все круто а на практике - ну вы
    > в курсе, да? Система без софта под нее - и даром
    > никому не нужна. Осталось только убедить авторов прикладух не юзать gcc'измы,
    > и дело в шляпе :)

    Прикинь: FreeBSD полноценно работает без ПО, собранного GCC из коллекции портов (тупо каталог /usr/local пуст). При этом может работать роутером (IPF, PF, IPFW) и файлсервером (NFS, FTP), работает SSH, пользовательская консоль (sh, tcsh).
    Заметь: GCC для поднятия этого УЖЕ не нужен!


     
     
  • 6.59, User294 (ok), 01:58, 04/04/2011 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > каталог /usr/local пуст). При этом может работать роутером (IPF, PF, IPFW)

    Ололо :) у меня роутер работал даже когда libc убился. Кернелу на это libc и прикладной крап вообще плевать :) оно там живет своей жизнью, пакетики гоняет. Правда, боюсь что мало кто разделит такой оптимизм.

    > и файлсервером (NFS, FTP), работает SSH, пользовательская консоль (sh, tcsh).

    Ну прямо достижения дедов и прадедов повторили. Круто, круто! :)))

    > Заметь: GCC для поднятия этого УЖЕ не нужен!

    Да вообще, хана этому праааааативному гцц, однозначно :).

     
  • 6.79, anonymous (??), 15:31, 06/04/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Прикинь: FreeBSD полноценно работает без ПО, собранного GCC из коллекции портов (тупо
    > каталог /usr/local пуст). При этом может работать роутером (IPF, PF, IPFW)
    > и файлсервером (NFS, FTP), работает SSH, пользовательская консоль (sh, tcsh).
    > Заметь: GCC для поднятия этого УЖЕ не нужен!

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

     
  • 5.54, vle (ok), 21:01, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Исходный код FreeBSD написан на ISO-стандартном языке. Коммит gcc'измов запрещён. Оптимизировать
    >> под "ещё один компилятор" никто не будет.
    > Как обычно, в теории все круто а на практике - ну вы
    > в курсе, да? Система без софта под нее - и даром
    > никому не нужна. Осталось только убедить авторов прикладух не юзать gcc'измы,
    > и дело в шляпе :)

    Авторы "пликладух" среагируют только тогда, когда разные компиляторы,
    на горизонте появятся. И они появляются, clang и pcc, так что процесс УЖЕ идет.
    Задача номер два -- пакетировщикам софта в дистрибутивах не
    держать патчи у себя, а пинать апстрим as soon as possible.

     
     
  • 6.78, anonymous (??), 15:28, 06/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Авторы «пликладух» среагируют только тогда, когда разные компиляторы,
    > на горизонте появятся.

    и при этом если они будут поддерживать расширения gcc. иначе — «пишите патчи, господа». я, например, вовсю «gcc'измами» пользуюсь, и отказываться от них (а там есть вкусного, да) только из-за того, что на других компилерах не собирается… неа. пусть другие компилеры допиливают поддержку gcc, это de-facto стандарт.

     
  • 4.86, netch (ok), 09:18, 12/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Исходный код FreeBSD написан на ISO-стандартном языке. Коммит gcc'измов запрещён.

    Ну, честно говоря, это не совсем так, есть явные исключения - встроенный ассемблер, разнообразные __attribute__(). Именно поэтому основным путём сейчас рассматривается переход на clang (который старается уметь все расширения gcc), а не pcc, хотя весь userland стараются прогнать через другие компиляторы (и icc, и pcc, и TenDRA...) чтобы получить оценку проблем конкретных кусков.
    Но это те gcc'измы, которые "неизбежное зло".

     

  • 1.16, Vitold S (?), 12:12, 03/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > так ведь бсдшники всегда с 1913 годом сравнивают

    благодаря этому и сегодня опыт полученный 20 лет назад полезен пользователям BSD. ну разве, что новые команды появляются.

    Чего не скажешь о Apple и Microosft где каждый год новая идиотская идея убить все что было раньше и переписать по новой. в свое время я изучаю Quick Basic и писал на нем лабы, а спустя пару лет дети пишут лабы на Visual Basic, а сегодня Visual Basic .NET, а ведь для базового понимания алгоритмов эти все обвесы не нужны.

    P.S. Мой поклон и уважение BSD-шникам. Ценим и любим!

     
     
  • 2.21, d (??), 12:56, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    При чём здесь эппл и быдло.нет? То, что бсдшники написали ещё один компилятор - это, безусловно, плюс. Но лицензионные проблемы - это их проблемы, они не должны сказываться на объективном сравнении компиляторов. Нужно сравнивать современные версии: 4.6 и 1.0, или 4.1.3 и что_там_было_у_pcc. Иначе 1913 год.
     
     
  • 3.27, q1 (?), 13:46, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    И много дистрибутивов используют версию 4.6?
     
     
  • 4.39, botman (ok), 15:58, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы не с того конца зашли, даже в Debian oldstable входит GCC 4.3.2, а так кругом GCC 4.4.5 или около того... то что GCC 4.6 ещё не внедрили даже в testing-дистрибутивы вина его молодости, и это никак не связано с проблемами BSD-шников с их отношением к GPL3.
     
  • 4.50, denis111 (ok), 17:44, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    http://www.archlinux.org/packages/?sort=-last_update&q=gcc&maintainer=&last_u
     

  • 1.19, ImPressed (ok), 12:27, 03/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Больше компилеров, хороших и разных. Линус кстати в последнее время очень ругал GCC за оптимизацию кода, которая в некоторых случаях ломает бинарники и те вываливаются в Segmentation Fault ( сам пару раз вставал на такие грабли с -O0 код работает, даем -O2 в надежде выиграть пару % производительности, но при этом получаем SIGSEGV сразу же после старта). Наиболее часто бинарники валятся после борки с оптимизацией, если в коде были ассемблерные вставки.
     
     
  • 2.25, iZEN (ok), 13:37, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > сам пару раз вставал на такие грабли с -O0 код работает, даем -O2 в надежде выиграть пару % производительности, но при этом получаем SIGSEGV сразу же после старта

    Интересно, результаты компиляции PCC сравнивают с результатом компиляции под какой опцией GCC, с "-O0" или "-O2"?

     
     
  • 3.40, астронимус (?), 16:03, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >сборка тестового комплекта ByteBench, выполненная при помощи gcc 4.1.3 (режим оптимизации "-O2")
     
     
  • 4.63, User294 (ok), 02:11, 04/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>выполненная при помощи gcc 4.1.3

    А чего не с 2.95 то? А то уже 4.6 вышел... если уж хочется показать забористость результатов, сравнение с 2.95 будет еще эпичнее чем с 4.1.3...


     
     
  • 5.66, mma (?), 07:04, 04/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    потомучто 4.1.3 это последняя версия которая устраивает бздунов по лицензии
     
     
  • 6.68, тигар (ok), 10:25, 04/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > потомучто 4.1.3 это последняя версия которая устраивает бздунов по лицензии

    прежде чем писать х.ню ознакомьтесь с вопросом. пожалуйста.

     
  • 2.42, Dan (??), 16:05, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Поставил убунту на самособраное ядро с -O3. Как видишь вся ок. ЧАДНТ?
     
     
  • 3.46, ImPressed (ok), 17:18, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Поставил убунту на самособраное ядро с -O3. Как видишь вся ок. ЧАДНТ?

    Я уже писал выше - что все очень специфично к коду, который написан. У меня в генте например не хотел glib с высокими оптимизациями работать, на некоторые пакеты emerge выводил предупреждение, что он убирает -Ox и -march=/-mtune= из CFLAGS ввиду того что пакеты с этими  опциями сборки некорректно работают.
    Ядро и с -O6 неплохо собирается, вот только толку особого от этого нет=)


     
     
  • 4.69, ананим (?), 08:42, 05/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    вот это:
    >-march=/-mtune=

    брехня. полная при чём.

    едиственное на что матюги видел - этого на оптимизацию с графитом.
    что в общем и логично.
    а матюги на архитектуру - это точно брехня.

     
     
  • 5.70, ImPressed (ok), 09:03, 05/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > вот это:
    >>-march=/-mtune=
    > брехня. полная при чём.
    > едиственное на что матюги видел - этого на оптимизацию с графитом.
    > что в общем и логично.
    > а матюги на архитектуру - это точно брехня.

    glib (не glibc)с -mtune=generic -O0 собирается и hald/dbus работают без граблей, с -mtune=core2 -O3 собирается но не работают ( SegFault) hald и dbus.
    Не знаю, может звезды были не в положении для emerge, но не работало - хоть убей.

     
     
  • 6.82, anonymous (??), 15:38, 06/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Не знаю, может звезды были не в положении для emerge, но не
    > работало - хоть убей.

    потому что -O3 включает в себя некоторые "опасные" оптимизации. о чём написано в документации gcc, но чукчи же не читатели.

     
  • 4.81, anonymous (??), 15:36, 06/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Ядро и с -O6 неплохо собирается, вот только толку особого от этого
    > нет=)

    конечно, нет, потому что цифра больше 3 в -O значит ровно то же самое, что и тройка. хоть -O9. за пруфами — welcome в исходники или список рассылки gcc, где этот вопрос с завидной пероидичностью задают.

     
  • 3.60, User294 (ok), 02:02, 04/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Поставил убунту на самособраное ядро с -O3. Как видишь вся ок. ЧАДНТ?

    "Если вам кажется что дела идут хорошо, значит вы просто чего-то не заметили" (законы Мерфи). Как-то так исторически лично я натыкался на глюки после юзания -O3 у гцц. При том порой - на редкие и трудноуловимые. Оно, конечно, можно - всяких флагов навинтить. Только потом придется мозг ломать - чьи глюки: программы или компилятора. Заведомо стабильные оптимизации идут в -O2, а то что выше - на свой зад уже ;). Кстати данный тезис и бсдунов вполне касается - если они думают что баги есть только в GCC - они это, оптимисты-идеалисты, видимо :)

     
     
  • 4.88, netch (ok), 09:31, 12/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Поставил убунту на самособраное ядро с -O3. Как видишь вся ок. ЧАДНТ?
    > "Если вам кажется что дела идут хорошо, значит вы просто чего-то не
    > заметили" (законы Мерфи). Как-то так исторически лично я натыкался на глюки
    > после юзания -O3 у гцц. При том порой - на редкие
    > и трудноуловимые. Оно, конечно, можно - всяких флагов навинтить. Только потом
    > придется мозг ломать - чьи глюки: программы или компилятора. Заведомо стабильные
    > оптимизации идут в -O2, а то что выше - на свой
    > зад уже ;). Кстати данный тезис и бсдунов вполне касается -
    > если они думают что баги есть только в GCC - они
    > это, оптимисты-идеалисты, видимо :)

    Ты тоже оптимист. Есть широко известный глюк gcc 2.9* при сборке squid при -O1 или -O3, но не -O2 :)

    Вообще отношение к оптимизациям у  gcc некорректное. Во-первых, хотя info говорит, что эти уровни разлагаются на кучу отдельных параметров, в коде дофига прямых проверок типа if (optimize > 0). Во-вторых, при -O1 уже уезжают номера строк, а при -O0 может генерироваться 10 команд с пинг-понгом между регистрами, запись в стек и вычитка записанного обратно, и т.д.; в результате код дико неэффективен. Правильного же промежуточного уровня - какие угодно оптимизации, но в пределах отрезка кода между двумя sequence point - там нет.

     
     
  • 5.89, ImPressed (ok), 09:36, 12/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > Ты тоже оптимист. Есть широко известный глюк gcc 2.9* при сборке squid
    > при -O1 или -O3, но не -O2 :)
    > Вообще отношение к оптимизациям у  gcc некорректное. Во-первых, хотя info говорит,
    > что эти уровни разлагаются на кучу отдельных параметров, в коде дофига
    > прямых проверок типа if (optimize > 0). Во-вторых, при -O1 уже
    > уезжают номера строк, а при -O0 может генерироваться 10 команд с
    > пинг-понгом между регистрами, запись в стек и вычитка записанного обратно, и
    > т.д.; в результате код дико неэффективен. Правильного же промежуточного уровня -
    > какие угодно оптимизации, но в пределах отрезка кода между двумя sequence
    > point - там нет.

    Согласен, оптимизатор в GCC иногда настолько суров и беспощаден, что бинарь после компиляции валится в кору, особенно если со всякими -ffast-math -O3 -funroll-all-loops -falign-* перемудрить.

     
  • 2.80, anonymous (??), 15:34, 06/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > такие грабли с -O0 код работает, даем -O2 в надежде выиграть
    > пару % производительности, но при этом получаем SIGSEGV сразу же после старта).

    а что на это говорят -Wall и valgrind?

    > Наиболее часто бинарники валятся после борки с оптимизацией, если в коде были ассемблерные вставки.

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

     
     
  • 3.90, ImPressed (ok), 09:39, 12/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> такие грабли с -O0 код работает, даем -O2 в надежде выиграть
    >> пару % производительности, но при этом получаем SIGSEGV сразу же после старта).
    > а что на это говорят -Wall и valgrind?
    >> Наиболее часто бинарники валятся после борки с оптимизацией, если в коде были ассемблерные вставки.
    > удивительно, не так ли? а не надо их писать, если не знаешь,
    > какой код компилятор нагенерит.

    Ваши бы слова да богу в уши=). Иногда без инлайнового ассемблера просто не обойтись, вот и приходится изощряться.

     
     
  • 4.91, anonymous (??), 10:31, 12/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Ваши бы слова да богу в уши=). Иногда без инлайнового ассемблера просто
    > не обойтись, вот и приходится изощряться.

    в отдельную либу, её с -O0, не забыть пояснить компилятору, какие регистры дохлые.

    кстати, а можно поинтересоваться: зачем инлайн-асм? именно вот вмонтированый в сишный исходник асм мне — дай демона памяти — за 10+ лет ни разу не понадобился. вообще, могу вспомнить только случаи конверсии бэкбуфера в разный BPP да софтварного текстуризатора — там пришлось асм делать.

     
     
  • 5.92, ImPressed (ok), 10:39, 12/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ваши бы слова да богу в уши=). Иногда без инлайнового ассемблера просто
    >> не обойтись, вот и приходится изощряться.
    > в отдельную либу, её с -O0, не забыть пояснить компилятору, какие регистры
    > дохлые.
    > кстати, а можно поинтересоваться: зачем инлайн-асм? именно вот вмонтированый в сишный исходник
    > асм мне — дай демона памяти — за 10+ лет ни
    > разу не понадобился. вообще, могу вспомнить только случаи конверсии бэкбуфера в
    > разный BPP да софтварного текстуризатора — там пришлось асм делать.

    Была задачка надо было с MSR-регистрами работать с юзерленда. Отдельную либу городить - муторно, а пару __asm__ volatile () втыкнуть в код функции много проблем не доставляло.
    И второй случай из недавнего читалка TSC-регистра (а-ля команда RDTSC) дабы сэкономить пару байт ( функция как раз кончалась на этой ассемблерной вставке) эпилог функции был перенесен мною в эту самую многострадальную __asm__ volatile(), с -O0 все прекрасно, даже с просто -O Segmentation Fault. Как мне кажется GCC делает оптимизацию работы со стеком и мой выкрутас поломал логику оптимимзатора ( хотя не должен был) и я получил SegFault.

    Ну тут может и я был ССЗБ, но как мне кажется результат все равно должен был быть удобоваримым. В задачке с TSC нужно было реализовать софтварный HPET-таймер с завязкой на Timestamp counter процессора. Пришлось в качестве решения проблемы убирать эпилог функции из __asm__() и дать компилеру построить его самому.

     
     
  • 6.93, netch (ok), 11:25, 12/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > И второй случай из недавнего читалка TSC-регистра (а-ля команда RDTSC) дабы сэкономить
    > пару байт ( функция как раз кончалась на этой ассемблерной вставке)
    > эпилог функции был перенесен мною в эту самую многострадальную __asm__ volatile(),
    > с -O0 все прекрасно, даже с просто -O Segmentation Fault. Как
    > мне кажется GCC делает оптимизацию работы со стеком и мой выкрутас
    > поломал логику оптимимзатора ( хотя не должен был) и я получил
    > SegFault.

    Эпилог - да, делать точно не стоило.
    Просто описать команду и результаты.

     

  • 1.20, yantux (??), 12:37, 03/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Захотел попробовать скачать под ms windows-не нашёл бинарников.
     
  • 1.28, Аноним (-), 13:47, 03/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ого! Вот это новость. Я уже думал, что ту яму не найдут и не откопают. А оно эвон как вышло.
     
  • 1.41, Анонимно (?), 16:03, 03/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Зачем сейчас ещё один компилятор С на С? Уже десять раз бы обогнали всех по качеству генерируемого бинарника, если бы на джаваскрипте писали или схеме.
     
     
  • 2.47, ImPressed (ok), 17:19, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Зачем сейчас ещё один компилятор С на С? Уже десять раз бы
    > обогнали всех по качеству генерируемого бинарника, если бы на джаваскрипте писали
    > или схеме.

    Что мелочиться, давайте уж тогда на Барсике от ZX-Spectrum напишем =)

     
     
  • 3.52, Michael Shigorin (ok), 18:37, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    (off) Барсик же вроде для писишек, а не спектрумов, заявляли? :)

    http://www.gamedev.ru/code/forum/?id=90972&page=2#m21

    PS: вообще да, они б по скорости кода ещё с пресловутым 2.7.x.y сравнили...

     
     
  • 4.55, z (??), 21:48, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Новые версии GCC далеко не всегда и не во всём быстрее старых (как по времени компиляции так и покачеству герерируемого кода), проверено не раз на scimark2k
     
  • 4.61, User294 (ok), 02:04, 04/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > (off) Барсик же вроде для писишек, а не спектрумов, заявляли? :)
    > http://www.gamedev.ru/code/forum/?id=90972&page=2#m21

    О, кто-то тоже видел этот доисторический "Power Saving" и "умный дом", все в одном. Новое - это хорошо забытое старое...  

     
  • 4.64, anonymous vulgaris (?), 02:37, 04/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > (off) Барсик же вроде для писишек, а не спектрумов, заявляли? :)

    GLBasic
    Write a program once, then compile for Windows, Apple Mac OS X. Start your iPhone development, Linux, PocketPC (Smartphone and Windows Mobile) and GP2X/Wiz without changing the source code at all.
    http://www.glbasic.com/


    DarkBASIC - The Ultimate 3D Games Creator
    DarkBASIC allows you to create your own games, demos, slideshows, even business applications using the easy to understand BASIC programming language. Even if you've never coded before, just follow the in-depth tutorials and you'll be generating results in minutes! Harness the power of Direct X and make 3D objects come to life in just a few simple commands.
    http://www.thegamecreators.com/?m=view_product&id=2030

     
  • 3.53, Анонимно (?), 19:20, 03/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Что мелочиться, давайте уж тогда на Барсике от ZX-Spectrum напишем

    Используют же lex, yacc, что сейчас мешает использовать более подходящий, нежели C, способ работы с деревьями?

     
     
  • 4.75, Mna (??), 14:43, 06/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Используют же lex, yacc, что сейчас мешает использовать более подходящий, нежели C,
    > способ работы с деревьями?

    Это JavaScript или Scheme на деревья ориентированный? а получше ничего нет??

     
  • 2.62, User294 (ok), 02:10, 04/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > если бы на джаваскрипте писали

    Угу, так и представляю себе компилер с временем запуска оного как у браузеров... oO

     
     
  • 3.83, anonymous (??), 15:43, 06/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Угу, так и представляю себе компилер с временем запуска оного как у
    > браузеров... oO

    то есть, мгновенно, как моя опера? нормально, устраивает.

     
  • 2.87, netch (ok), 09:27, 12/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Зачем сейчас ещё один компилятор С на С? Уже десять раз бы
    > обогнали всех по качеству генерируемого бинарника, если бы на джаваскрипте писали
    > или схеме.

    1. На Javascript - точно не обогнали бы. А какая-то специфическая форма LISP у gcc внутрях, используется на всю катушку, но супер-достижений не видно. Просто почти оптимум.
    2. Независимая простая реализация в качестве контрольной - обязательная штука в сложных системах. Как-то даже для сравнительно простой криптографии я писал 4 реализации: C/OpenSSL, C/GnuTLS, Python и Erlang. Зато в результате я смог каждому участнику дать все 4 и сказать "вот канонический набор реализаций, сдирай код сколько угодно, но твоя реализация должна давать идентичный результат". А компиляторы диагностировать обычно сложнее криптографии.

     

  • 1.84, iZEN (ok), 01:12, 07/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Обновился порт lang/pcc на FreeBSD: http://www.freshports.org/lang/pcc/
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру