LINUX.ORG.RU

Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.


0

0

В недавней дискуссии в lkml Linus Torvalds заявил, что он согласен отказаться от использования GCC в пользу более быстрого и маленького C копилятора (если такой появится) и согласен изменить кернел в плане отказа от использования gcc extension. Линус утверждает что проблема с GCC заключается в том что основной девелопмент и оптимизация ведется в C++, Ada, Fortran и другихх направлениях,, в то время как обычный C уже никого (из gcc девелоперов) не интересует, и большинство недавно добавленных оптимизаций не имеют никакого смысла для проэктов написанных на C.

Итак, дело за малым, у кого есть маленький и быстрый C компилятор, который умеет инлайновый ассемблер и инлайновые функции? (кроссплатформенность необязательна, но желательна).

>>> Письмо Линуса в lkml

★★★★★

> Итак, дело за малым, у кого есть маленький и быстрый C компилятор, который умеет инлайновый ассемблер и инлайновые функции? (кроссплатформенность необязательна, но желательна).

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

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

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

green ★★★★★
() автор топика

А смысл какой? Все равно все собирать будут c gcc... Лучше уж довести до ума gcc. Я думаю, Линус просто хочет обратить внимание общественности на существующую проблему.

ANDI ★★
()

Что-то вы бредите.
Линус высказался за быстрый и маленький С компилятов в плане разделения gcc на модули по языкам в проектном плане, а не в плане поиска другого компилятора.

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

anonymous
()

green папарацци, любитель желтых заголовков :))

anonymous
()

Зачем это? Ядро 2.4.20 собирается на Athlon 1800 за 4 минуты. Ну, модули минут 10. Вообще, разве есть притензии к скорости компиляции? У меня - нет. Я вообще понять не могу, почему linux-сообщество ломится в открытую дверь? Все стремятся улучшать то, к чему притензий нет, а вот наиболее животрепещущие проблемы как-то стороной обходятся.

Eugene_Korobko
()

Хмм... Из письма Линуса совсем не следует что он хочет отказаться от gcc. Более того, такой шаг был бы имхо большой глупостью, а переход на закрытый компилятор - вообще верх идиотизма.

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

Читайте тред! зря я чтоли ссылку на архив привел?

I don't think being architecture-specific is necessarily a bad thing in compilers, although most compiler writers obviously try to avoid it.

http://marc.theaimsgroup.com/?l=linux-kernel&m=104439696917472&w=2

И про _другой_ компилятор (не GCC) он тоже писал. Листайте тред.

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

Генерится неоптимальный код, вот на что обращает внимание Linus и другие.

15 минут на сборку кернела тоже жалко, тебе может и все равно, а я в день собираю не один десяток кернелов.

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

Речи о закрытом компиляторе действительно не идет. Но все-таки ЛИСТАЙТЕ ТРЕД. Новый компилер не обязательно должен быть gcc.

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

Линус ч етко дал понять что коммерчески cc и cc со странными лицензиями (типа lcc) ему не подходят, потому как их нельзя исправить в случае чего. Так что речь об использовании закрытого компилятора для компилирования Linux kernel - не идет.

green ★★★★★
() автор топика

> 15 минут на сборку кернела тоже жалко, тебе может и все равно, а я в день собираю не один десяток кернелов.

Ценой годичных усилий и переписывания пол-gcc время сборки кернела доведут до 10 минут, green будет счастлив, зато заявится другой перец, который в день собирает две сотни ядер хер знает зачем, и будет требовать чтобы под него все прогнулись.

Мое мнение такое, что пока gcc не проигрывает в разы по скорости компиляции другим компиляторам такого же класса, что-либо оптимизировать тут нет смысла. Последние лет 10 любая оптимизация перекрывается грубой силой - апгрейдом на проц/память получше, вот и все дела.

anonymous
()

gcc

2anonymous (*) (2003-02-05 13:22:37.483):
Важна не скорость компиляции(это вторично), а оптимальность исполняемого кода. Если бы ты хоть раз смотрел ассемблерные листинги выдаваемые gcc (даже с -O3), ты бы понял о чём речь.

Z
()

Идея насчет исключения gcc-extentions из ядра весьма уместна. Глядишь, под такую лакомую задачу и компиляторы появятся, да и еще будут друг с другом соревноваться - нам всем только на пользу :) Вот только самый простой (IMHO) и весьма правильный путь - развивать оптимизацию в старом добром gcc. Как я понимаю, оптимизация на уровне языка C (т.е. весьма низком) целиком и полностью пригодится и во всех остальных языках, поддерживаемых gcc.

>15 минут на сборку кернела тоже жалко, тебе может и все равно, а я в >день собираю не один десяток кернелов.

Ну вот ты и доработай gcc - скомпилируешь его по-новому и будет он тебе на щастье работать в 2 раза быстрее.

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

Это не моя специализация. Я (да и не только я) бы лучше заплатил за такой девелопмент, только вот никто что-то не предлагает услугу по ускорению/улучшению gcc за деньги (и чтоб результат обратно в mainstream gcc сразу замержили, ясное дело).

green ★★★★★
() автор топика

грубую силу можно применить забивая что-нибудь тебе в задницу :)

а для сердца системы нужна максимальная оптимизация

SG

anonymous
()

> Важна не скорость компиляции(это вторично), а оптимальность исполняемого кода. Если бы ты хоть раз смотрел ассемблерные листинги выдаваемые gcc (даже с -O3), ты бы понял о чём речь.

А я и смотрел и вообще в курсе этого. Не надо тему менять как вам хочется. Человек распинался про _скорость_ компиляции, я ему и ответил про нее же. Будете говорить про качество генеренного кода - буду отвечать про него же.

anonymous
()

SG модный спец видимо не раз обученный по методу грубой силы. Не надо тут юношеских заявлений, какая оптимизация нужна для "сердца системы". Если бы все разработчики ОС ждали лет по 20 пока появится супер-пупер оптимизирующий компилятор (с потолка типа упадет), а потом начинали писать ядра - где бы мы все счас были, ага?

Олухи какие-то малолетние, все комментарии по типу "компилятор гавно, ваще ниче делать нельзя и не буду"

anonymous
()

Хм... :-) Ну, например, по сравнению с Борландовскими поделками, GCC - еще вполне даже и весьма ничего себе... :-)
Вы посмотрите, КАКОЙ код генерится Борландом или Макросаксом - потом уж выпендривайтесь... :-)))

В общем, всё познается в сравнении.

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

В том же треде есть ссылки на то что один и тот же сырец скомпиленный MS VC и gcc, в случае с MSVC работает в два-три раза быстрее чем в случае с gcc

green ★★★★★
() автор топика

Если вы собираете не один десяток и под одну архитектуру, то все остальные ядра (кроме первого) будут собираться на порядок быстрее - не будут пересобираться все модули. Только обязательные обновятся.

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

Это только если не делать make distclean. компиляция кажный раз в новом дереве будет занимать кажный раз много времени.

green ★★★★★
() автор топика

Угу. Обновятся... А если не обновятся? Чеши потом репу почему ядро не пошло. Надежнее всего make clean dep modules bzlilo

anonymous
()

>SG модный спец видимо не раз обученный по методу грубой силы. Не >надо тут юношеских заявлений, какая оптимизация нужна для "сердца >системы". Если бы все разработчики ОС ждали лет по 20 пока появится >супер-пупер оптимизирующий компилятор (с потолка типа упадет), а >потом начинали писать ядра - где бы мы все счас были, ага? >Олухи какие-то малолетние, все комментарии по типу "компилятор >гавно, ваще ниче делать нельзя и не буду"

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

в середине 90х были компы типа п166 и они справлялись с запросами _того_ времени, например, были роутером/фаерволом для сети 10 мбит.

и если сегодняшний роутер на п1660 не сможет роутить 100 мбит, то нахрен оно нада?

SG

anonymous
()

Я пытался проверить некоторые реальные программы, типа gzip, oggenc и др., компилируя их интеловским icc и gcc. gcc почему-то всегда на бенчмарках выдавало лучшие результаты, чем icc. При этом в специально написанных тестах (типа циклов, вложенных друг в дружку) icc выдавало прирост производительности более чем на порядок - а то и раз в 20.

anonymous
()

>>Зачем это? Ядро 2.4.20 собирается на Athlon 1800 за 4 минуты. Ну, модули минут 10.
А надо - СЕКУНД за 10.
Чтобы при инсталляции дистр сам ядро настраивал :)))
А действительно, нехорошо иметь ядро продо всё на свете. А масса модулей -
проблемы при автоопределении при загрузке.
Лучше - обнаружено новое устройство(как в виндах :))) ), выполняется
перекомпиляция ядра :))) Готово, теперь необходимо произвести перезагрузку.
А, кроме шуток... Может, правда так и надо.
И вообще неудобно 10 мин. ждать. А это - на одной из лучших машин
(у меня Athlon TB 1200, цифры отличаются несильно)

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

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

А вот не надо мне выдуманных слов приписывать. Где я сказал, что оптимизация "нахер не нужна", цитату плиз. Я сказал всего лишь очень простую мысль, что нет смысла тратить туеву хучу человекочасов на то, что и так само по себе постоянно улучшается (производительность компов). Вы же не собираете сейчас ядра десятками на 486? Вот когда железячный рост затормозится, тогда и пойдут в дело наработки по оптимизации софта, ибо резерв за эти годы там накоплен просто немеряный.

anonymous
()

> В том же треде есть ссылки на то что один и тот же сырец скомпиленный MS VC и gcc, в случае с MSVC работает в два-три раза быстрее чем в случае с gcc

Мне кажется, это слишком смелое высказывание. Я только нашёл замечание, что функция быстрого преобразования Фурье, скомпилированная egcs-какой-то-там-дремучей-версии, на 50% медленнее той же функции, скомпилированной MSVC 6.0. Ну и что?

То, что icc циклы определённого оптимизирует очень хорошо - тоже известный факт. У интела очень хороший автоматический распараллеливатель, и он иногда может распараллеливать в MMX, SSE и т. д. Для фортрана и вообще численных приложений это очень хорошо, для ядра ОС и других нечисленных приложений - почти всегда по барабану.

tilde

anonymous
()

> А надо - СЕКУНД за 10. Миллион строк кода?

anonymous
()

Для того чтобы делать что-нибудь оптимизированное (тот же компилятор), нужен не хаос а порядок. GPL-ные творческие рвения в основном хаос, а для того чтобы делать что-нибудь фундаментальное, нужна наука. И управлять этим должен кто-нибудь. А там где наука, там нужны бабки и немалые. Мля, нужна хоть какая-нибудь структура, которая координировала все это, но это противоречит GPL. Выход пока наметился - опенсорс родимый. OSDN не здря ведь появился.

Не имел целью ущемить GPL, но сие есть действительность. Либо нужен GPL 3.0 с учетов всего этого, либо будущее GPL обречено.

OpenStorm ★★★
()

> тогда и пойдут в дело наработки по оптимизации софта, ибо резерв за эти годы там накоплен просто немеряный.

Мда. Мне кажется, Вы выдаётся желаемое за действительное. Ничего существенно нового в оптимизации за последние 10 лет придумано не было. Более того, эта тема сейчас даже и не особенно популярна в исследовательских кругах, так как считается, что почти всё, что можно выжать из программы, уже выжато, и дальнейшие оптимизации слишком дороги по отношению цена/качество.

Достаточно актуальна ещё "profile-based" оптимизация. Это когда один раз программа компилируется с инструментацией, собирается статистика, затем она перекомпилируется с учётом собранной статистики. Она в некоторых случаях может дать +30% к производительности. Я вот только не знаю, пробовали ли её применять к Linux kernel.

tilde

anonymous
()

2 Eugene_Korobko (*) (2003-02-05 12:16:14.473)

> Зачем это? Ядро 2.4.20 собирается на Athlon 1800 за 4 минуты. Ну, модули минут 10.

Явный перебор. У меня почему-то на Athlon XP1900+/512Mb сборка ядра с модулями с заворачиванием в deb занимает 4:30 - 5:00 мин.

Debian/unstable, 2.4.21-pre4-rmap15d-2, gcc (GCC) 3.2.2 20030131 (Debian prerelease)

Где то что-то очень криво у Вас отстроено.

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

> Будущее GPL обречено.
Ну ты прямо оракул =)

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

> Мда. Мне кажется, Вы выдаётся желаемое за действительное. Ничего существенно нового в оптимизации за последние 10 лет придумано не было.

Опять мне что-то левое приписывают... Я сказал "по оптимизации софта", а не только компилятора. Я не говорил про революционные мысли в оптимизации. Я говорю про то, что успело вырасти поколение программистов, которое проблем оптимизации вообще НЕ ВИДИТ; которые пишут совершенно дурной код, тормоза которого маскируются быстрым железом. Вот если эти помойки выгребать, порой в 20 строках кода получаешь прирост производительности 100-200%.

> Более того, эта тема сейчас даже и не особенно популярна в исследовательских кругах, так как считается, что почти всё, что можно выжать из программы, уже выжато, и дальнейшие оптимизации слишком дороги по отношению цена/качество.

В исследовательских-то понятно, там уже воз и маленькая тележка диссертаций на эту тему. А вот с претворением идей в реальный код еще непаханая целина...

anonymous
()

У меня P4-1.8A, 512Mb DDR PC2100, HDD: WC 40Gb 7200rpm 8mb cache.
Компиляция ядра (2.4.20) - 3.5 минуты. Если вырубить всякую ерунду типа поддержки USB, записи на UDF, (еще чего-то там, уж и не помню), то сборка ядра - менее 3-х минут.

Дистр Slackware 8.1, gcc 2.95.3

P. S. Как нибудь закину инфу о компиляции ядра на 2*PIII-1000, 1Gb RAM и на PIII-1200, 512Mb RAM.

R00T
()

2ROOT gcc-2.95.x компилирует заметно быстрей чем 3.2.x, это вроде как изветный факт.

что-то не очень у вас результат, на атлонах с PR поменьше результат примерно такой-же (с USB,SCSI итд)

PS. флейм: атлоны рулят! :)

anonymous
()

http://www.q-software-solutions.com/qide/ а кто знаком с этим ? я юзал win версию - вполне хорошая весчь ! и бесплатная (на сайте разработчика) и доки к ней написаны очень интересные , парень - большой энтузиаст :)

ive

anonymous
()

Интересная беседа %) Все приводят какие то цыфры (по времени) не приводя что собсно то за ядро компилили. (не версию у смысле, а сонфиг)

я собсно не засекал, но на 4 камневом серваке при -j 4 обрезаное ядро для терминала (без модулей вообще) я компилил около 2 минут (2.95.3), или даже меньше.. По крайней мере, конфигурация (make config) занимает куда больше времени.

Кстати, ядро - ядром, но для прикладух куда более важно оптимизация libc & libm.

И еще, насчет MSVC. Хороший компилер, не надо на него бочку катить, особенно основываясь на той идее что M$ = фуфло. Что собсно далеко не всегда верно.
Експериментаторам - возмите каку числодробилку (тест минут этак на 10) с кучей циклов, скомпилите gcc & VC6. exe потом пустите под wine. О скорости напишите %)





ifconfig
()

> Опять мне что-то левое приписывают... Я сказал "по оптимизации софта", а не только компилятора.

Ну, извините. Не так понял. В этом смысле совершенно согласен.

> В исследовательских-то понятно, там уже воз и маленькая тележка диссертаций на эту тему. А вот с претворением идей в реальный код еще непаханая целина...

Ну почему же... Всё претворяют потихоньку (с лагом лет в пять-десять). Интел в этом смысле вполне рулит. Другое дело, что, как я сказал, соотношение цена/качество уже такое, что ещё десять раз подумаешь.

tilde

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

Координация НЕ противоречит GPL'ю. Я бы даже скзаал наоборот, в GPL можно применить максимум плюсов именно координации. В остальных случаях (где обычно "вливают бабки), гораздо проще пинять силу, типа "это нужно сделать потому, что я сказал, а я начальник, у меня бабки".

bormotov ★★★☆
()

Бредовая идея с этим кернел-C компилятором. Не вдаваясь в подробности могу сказать следующее. Компактный компилятор нужен лишь тогда, когда памяти не хватает, оперативной или дисковой. У кого-то не хватает? Кроме того, компактный компилятор - это, как правило, более медленный и простой, а значит менее оптимизирующий компилятор. Оно вам надо? Открытость исходников компилятора и GPL-изм их лицензии - это скорее идеологическое нежели технологическое требование. Программиста на C должна волновать не версия компилятора, а соответствие программного кода стандарту и, разумеется, оптимальность алгоритма. Главное ваше требование - оптимальность получаемого после компиляции машинного кода. Для этих целей существуют платформо-специализированые компиляторы. Например есть компиляторы от Intel, от SGI, от Sun. Не устраивают эти компилаторы? Спецификации в зубы и вперёд совершенствовать gcc. Но в любом случае, не разработчика дело каким компилятором будет компилироваться его код. Две основные и IMHO единственые заботы нормального разработчика - соответствие стандарту/там и оптимизация кода на уровне алгоритма. Чем его код кто-то будет компилировать разработчика волновать не должно; главное - чтобы этот компилятор поддерживал тот же стандарт. Время компиляции тоже не непонятно откуда взялось как некое важное требование. Несмотря на увеличение и усложнение исходников Linux современные его версии собираются на современных же системах на порядок быстрее чем это было когда-то на 486 и с более простыми ядрами. Кто тут собирает ядро десятки раз на день? Такой перец, скорее всего, не менее часто собирает не только ядро, но и другии программы. Тогда, даже выполнение его абсоютно идиотского требования (собирать всё ядро не за 7 минут, а за 70 секунд), не решит всех его сексуальных проблем. Я бы (да и не только я) пожертвовал бы увеличением времени компиляции при условии получения более оптимальных бинарников. Особенно когда речь идёт о ядре.

Извинити за тон, просто надоела бредятина.

anonymous
()

P4-2.0A/512M, gcc-2.95.4 FreeBSD 4.7-STABLE kernel собирается за 1мин 3сек, пересборка всей системы 30мин (make world)

anonymous
()

2Eugene_Korobko

у меня на Celerone 1300 (Tualatin) ядро + модули собираются за 9-10 минут

bjohn

anonymous
()

господа, а есть ведь еще многопроцессорные системы и ключик -m для мейка... хотя меня скорость сборки ядра напрягала только на 486 и то не очень. и согласен с предыдущим оратором, что главное это оптимизация кода, а не скорость его сборки. когда сам програмил то просто на период отладки отключал все оптимизации, а релиз собирал оптимизированным.

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

SG

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

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

Товарищю с фрей - du -ks /usr/src/linux и du -ks /usr/src/sys не пробовал делать? Еще вопросы есть? :)

green ★★★★★
() автор топика

2green Есть контора, которая занимется оптимизациями gcc на заказ. http://www.codesourcery.com/gcc.html Я тоже несколько раз в день пересобираю ядро, но меня мало волнует время сборки, я готов этим жертвовать. А вот улучшение оптимизации - это реальный плюс, но это почти всегда будет вести к увеличению времени компиляции. Или к багам... что тоже вероятно :)

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

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

Вы бы это разработчикам ресурсоёмкого софта сказали (типа игр, графика, рендеринг и прочее)... Если бы не оптимизация, сейчас бы играли в тетрис минимум на P4 :)

На счёт Борландов: Delphi компилит прекрасно, сам потом дизассемблил и смотрел

rasmp
()

to green (*) (2003-02-06 10:13:11.176)

Линукса к сожалению не имею для того чтобы сравнить, /usr/src/sys 60M

/Dmitry

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