| |
| |
| |
| |
| 5.56, Аноним (-), 13:58, 04/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| –2 +/– |
Нет, в случае нерукожопого программиста. Переход FreeBSD на clang показал что таких, к счастью, большинство - clang'ом не собиралось не больше десятка процентов портов, из них большая часть исправлялась добавлением пропущенного #include (что, кстати, значит что в gcc'шной libstdc++ инклудится лишнее, если она это жрала), с USE_GCC остались единицы с реальными gcc'измами.
| | |
| |
| |
| 7.68, arisu (ok), 16:06, 04/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +4 +/– |
 > напомни, сколько шлангу пришлось из-за этого поддерживать гнутых/гцц-шных расширений?
при этом две самые полезные фичи так и не поддерживает: nested functions и statement expressions.
оно понятно, что хардкорные фанаты тверды в своём принципе «что было хорошо для наших дедов и отцов — то хорошо и для нас», но эти две фичи, как я уже писал, без мегаусложнения компилятора дают приятные бонусы. например, удобные однострочные макросы min/max, вычисляющие аргументы ровно один раз, или нечто вроде лямбд для тех же qsort()/bsearch(), которые (вроде-лямбды) могут быть объявлены прямо параметром и напрямую обращаться к переменным родительской функции.
но это, конечно, не Ъ.
| | |
|
| 6.79, Аноним (-), 09:29, 05/10/2013 [^] [^^] [^^^] [ответить] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +2 +/– | |
> Нет, в случае нерукожопого программиста.
Наверное это был сам Юрий Нежопорукий.
> Переход FreeBSD на clang показал что
...что они х#$рят на своей волне и ни с кем не считаются, ставя свои лицензионные бзики выше получаемого на выходе результата.
| | |
| |
| 7.101, linux must _RIP_ (?), 11:54, 07/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| –2 +/– |
> ...что они х#$рят на своей волне и ни с кем не считаются,
> ставя свои лицензионные бзики выше получаемого на выходе результата.
это вы о большинстве линуксоидных программистов? которые слов c-std .., POSIX, SUS боятся как огня ?:)
| | |
|
|
|
|
|
| |
| 3.18, Аноним (-), 07:57, 04/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| –19 +/– |
в общем, если поскипать бред, то получается, что преимуществ-то и нет. Сейчас все новые компиляторы, трансляторы и т.п. или пишутся с нуля, или используют LLVM в качестве бэкенда, а GCC с его обфусцированной архитектурой (привет параноику Столлману) никому нафиг не нужен :)
| | |
| |
| |
| 5.31, Человек (??), 09:55, 04/10/2013 [^] [^^] [^^^] [ответить] [↓] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| –11 +/– | |
А почему Oracle Solaris Studio свой компилятор включает ?
Зачем Intel свой компилятор продаёт ?
Зачем AMD пилит свой форк Open64 ?
Зачем IBM продаёт XL ?
Зачем The Portland Group продаёт свой компилятор ?
Это великие IT-компании, у которых достаточно компетенции для реализации своих собственных компиляторов. У Red Hat такой компетенции нет и они используют GCC.
GCC нужен ТОЛЬКО для компиляции ядра Linux и другого ПО, которое использует костыли от GCC (его очень мало). В ядре Linux содержатся куча костылей. Эти костыли используют костыли из GCC. Вот и всё.
Apple выкинула GCC и FreeBSD тоже.
Реально GCC НЕ НУЖЕН !
| | |
| |
| 6.41, Аноним (-), 11:43, 04/10/2013 [^] [^^] [^^^] [ответить] [↓] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
Ну да. Давайте теперь каждую программу тестировать в разных компиляторах вместо одного и собирать не только для разной архитектуры, но и производителя, ура товарищи, ура!
А заодно напомните, кто реально для работы на ПК(а не узкоспециализированном железе одной фирмы) будет это делать, заранее спасибо.
| | |
| |
| 7.57, Аноним (-), 14:02, 04/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +2 +/– |
> Ну да. Давайте теперь каждую программу тестировать в разных компиляторах вместо одного
> и собирать не только для разной архитектуры, но и производителя, ура
> товарищи, ура!
Не "давайте", а все нормальные люди так и делали всегда, потому что это повышает шанс ловли ошибок и несовместимостей. Посмотрите хотя бы travis ci, оно по умолчанию давно поддерживает как минимум gcc и clang. Но куда GNU'шным проприетарщикам это понять - у них одна архитектура - бyбунту.
| | |
|
| 6.45, Аноним (-), 12:28, 04/10/2013 [^] [^^] [^^^] [ответить] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +9 +/– | |
> А почему Oracle Solaris Studio свой компилятор включает ?
Потому что у санок вечно NIH был. Кстати, данный компилер - набор грабель и костылей, судя по отзывам "счастливчиков". Нафиг это ораклу? Думаю лишь потому что они по инерции катится с технологиями саней. Скорее всего они с их управлением сие утопят, вместе с солярисом. Барыжить базами можно и под линух, с ним даже удобнее: не надо пилить все в 1 рылo + под их базы лучше подойдет с btrfs-ом, в котором еще на этапе дизайна нужные ораклу рукоятки заложили, благо в те времена архитект у них и работал. Не вижу глобальных долговременных перспектив этого добра.
> Зачем Intel свой компилятор продаёт ?
Честно говоря - я не совсем понимаю. Наверное "они так привыкли". Ну то-есть начальная идея имела некий пойнт - генерация более качественного кода под их CPU. Но учитывая что они же стали коммитить оптимизацию и поддержку новых команд в GCC, я честно говоря все меньше понимаю смысл существования этой фигни. Судя по тому как много народа пользуется icc - не только я. Ну если полутора землекопам на всю планету оно полезно и интелу не в облом ради них это майнтайнить - да и флаг им в руки, вам жалко чтоли?
> Зачем AMD пилит свой форк Open64 ?
Еще одна загадка природы. Наверное их ответ чемберлену на icc. Реальных применений оного я вообще ни разу не встречал.
> Зачем IBM продаёт XL ?
Не знаю. Ну то-есть, могу предположить что они денег хотят, как и все корпорасы. Но если они хотят иметь дело с линухом и софтом в нем - там gcc и баста. И никто их спрашивать не будет. Т.к. для IBM компилеры явно не основная часть их бизнеса - думаю что они вполне себе будут допиливать gcc под свой power. Ну или их будут прижимать x86 и ARM, уж как им там удобнее.
> Зачем The Portland Group продаёт свой компилятор ?
Мало ли кто и чего продает в этом мире. Наверное тоже денег хочет. Ну, пусть хочет. Посмтрим много ли получит.
> Это великие IT-компании, у которых достаточно компетенции для реализации своих
> собственных компиляторов. У Red Hat такой компетенции нет и они используют GCC.
А интель тогда с фига ли патчи в gcc шлет? Или там гугель например?
> GCC нужен ТОЛЬКО для компиляции ядра Linux и другого ПО, которое использует
> костыли от GCC (его очень мало). В ядре Linux содержатся куча
> костылей. Эти костыли используют костыли из GCC. Вот и всё.
Уточним: gcc сроду использовался для всего этого. Это работает. При том довольно хорошо. За годы там более-менее поудавили баги и догнали оптимизацию до довольно приличного состояния, когда оно без проблем вставляет даже MSVS-у, считавшемуся когда-то лучшему по оптимизации.
> Apple выкинула GCC и FreeBSD тоже.
Я так рад за проприерасов и их подстилок. А мне какое до них дело?
> Реально GCC НЕ НУЖEН !
Кому? Проприерасам и их подстилкам? Окей, пусть идут на...й, я не возражаю :).
| | |
| |
| 7.75, arisu (ok), 18:34, 04/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +3 +/– |
> Это компилятор по-умолчанию в Linux'ах. Т.е. на данный момент это основной C/C++
> компилятор.
более того: это компилятор, вероятность наличия которого на какой-нибудь хитрой системе (или возможности поставить порт) очень близка к единице. поэтому имеет смысл писать код так, чтобы его мог прожевать gcc, а остальными компиляторами заморачиваться только по мере неленивости.
| | |
| |
| |
| Часть нити удалена модератором |
|
|
|
|
| 5.106, annulen (ok), 13:05, 07/10/2013 [^] [^^] [^^^] [ответить] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| –2 +/– |
 >> никому нафиг не нужен :)
> Ну да, кроме вон той толпени корпорасов типа IBM, интелов и еще
> 100500 всяких, билдующих им себе линух для своих железяк.
Тем временем парни из IBM уже запилили LLVM и Clang для Power и System Z.
| | |
| |
| 6.144, Аноним (-), 12:01, 10/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– | |
> Тем временем парни из IBM уже запилили LLVM и Clang для Power и System Z.
Осталось всего ничего: спустить фанатизм в унитаз и честно сообщить нам сколько лет gcc так уже умеет.
| | |
|
|
| |
| 5.67, arisu (ok), 15:57, 04/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +2 +/– | |
> Вам повторить про более лучшую оптимизацию и большее количество поддерживаемых платформ/архитектур?
бессмысленно, оно в этом ничего не понимает. достаточно пассажа про «обфусцированую архитектуру», чтобы это понять.
| | |
| |
| |
| 7.83, arisu (ok), 10:02, 05/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +2 +/– | |
да тут начинать надо с того, что никакой «обфусцированой архитектуры» в gcc нет: надо просто иметь рабочие мозги и понимать предметную область.
llvm же вполне хорош — для своих применений. правда, там с дизайном совсем не радуга с поняшами, но и это тут обсуждать смысла нет: фанбои тупые, а те, кому интересно состояние дел, и так знают.
| | |
|
|
|
|
|
|
| |
| 2.5, pavlinux (ok), 00:47, 04/10/2013 [^] [^^] [^^^] [ответить] [↓] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +4 +/– |
 > Скоро окажется, что gpu работает наравне с cpu ...
Еще лет 7-8 назад один из разрабов Nvidia вывалил на сайте developer.nvidia.com,
что они запускали ядро Linux на GeForce, вроде 6800GT. Пост исчез в течении двух дней,
разраба никто больше не слышал. :)
Чуть раньше, когда CUDA и OpenCL в планах даже не было, один чувак,
реализовал функции сортировки, сравнения строк на Жыфорсе. Его сайт
жил дольше, но не обновлялся ни разу.
| | |
| |
| 3.8, vitalif (ok), 00:58, 04/10/2013 [^] [^^] [^^^] [ответить] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
 А ещё был более-менее реальный proof of concept червя, живущего исключительно в памяти GPU и в ROM'е broadcom'овской сетевухи (она там тоже такая типа вся программируемая), и слущающего трафик.
| | |
|
| 2.37, анонимус (??), 11:17, 04/10/2013 [^] [^^] [^^^] [ответить] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +2 +/– |
Это никогда не случится :) Вы не особо представляете как вообще GPU работает. Для некоторых алгоритмов намного быстрее, а для некоторых наоборот намного медленнее. А вот решения AMD CPU + GPU - APU вполне жизнеспособны, как в свое время CPU + FPU.
| | |
|
| 1.9, rshadow (ok), 01:38, 04/10/2013 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +2 +/– |
 Странная эта борьба за новые языки и возможности. Все время пытаются сделать лазерный скальпель, когда вогруг все пилят только деревья. Надо бы культуру программирования и технологии в массы подтянуть, а не переизобретать очередной велосипед на очередном языке.
| | |
| |
| 2.12, Аноним (-), 03:32, 04/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
Речь скорее идет о изобретении инструментов переноса старого кода и инструментов в новые условия. Что с того, что новые условия это не лесопилка, а что то потоньше? Уровень среднего программера остается неизменным.
| | |
|
| |
| 2.16, Аноним (-), 07:22, 04/10/2013 [^] [^^] [^^^] [ответить] [↓] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
На миллионyю по счету просьбу засветить свой код, который лучше, будет традиционное мужественное самоотверженное молчание ? Часто незнакомых людей "редкостными извращенцами" в лицо называешь?
| | |
| |
| 3.59, arisu (ok), 14:36, 04/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +2 +/– |
> На миллионyю по счету просьбу засветить свой код, который лучше, будет традиционное
> мужественное самоотверженное молчание ? Часто незнакомых людей «редкостными извращенцами»
> в лицо называешь?
проси на здоровье, за спрос денег не берут.
| | |
|
| 2.22, Аноним (-), 08:42, 04/10/2013 [^] [^^] [^^^] [ответить] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– | |
> забавно, конечно, но редкостные извращенцы. что этот, что llvm-щики.
Предложи более прямой способ сгенерить шейдеры для GPU, например? Как ты понимаешь, заранее вообще неизвестно что там у юзеря: ати, нвидия, интел или вообще какой-нить ARM. Поэтому программа явно не может таскать с собой для этого предкомпилированный код.
| | |
| |
| 3.58, Аноним (-), 14:05, 04/10/2013 [^] [^^] [^^^] [ответить] [↓] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
>> забавно, конечно, но редкостные извращенцы. что этот, что llvm-щики.
> Предложи более прямой способ сгенерить шейдеры для GPU, например? Как ты понимаешь,
> заранее вообще неизвестно что там у юзеря: ати, нвидия, интел или
> вообще какой-нить ARM. Поэтому программа явно не может таскать с собой
> для этого предкомпилированный код.
Вы прям так спрашиваете как будто arisu разбирается в компьютерах и не просто так брякнул.
| | |
| |
| 4.76, Аноним (-), 19:21, 04/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| –2 +/– |
не мешай ему дилетанствовать c самовлюбленным апломбом, вон уже чуть ниже поток полился про "ощущения чуйств" на тему GCC. Замени GCC и LLVM на Коллайдер и систему жизнеобеспечения автономного модуля на Марсе, впрочем и митохондрии подойдут - суть не поменяется. Костьми ляжет, но ни слова не дождешься о конкретных проверяемых сущностях.
| | |
| |
| 5.77, arisu (ok), 19:29, 04/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +6 +/– | |
(пожимает плечами) конкретная сущность — это намертво зависающий движок регулярок, нежно портированый из plan9 и допиленый. тупой шланг не врубается, что inline-функция может модифицировать некоторые переменные, передаваемые ей в структуре (хотя никакого const там нет), поэтому сначала переменную где-то кэширует, а потом использует её старое значение. в итоге получается бесконечный цикл вида «jmp $». чего лично я от компилятора такого возраста никак не ожидал и был несколько в офигее, когда софтина подвисла, слопав весь процессор.
но я понимаю, что для тебя «я наступил на баг в компиляторе» — ситуация вообще невозможная, потому что твой «приветмир» без ворнингов вообще не собирается. какие уж там баги компилятора…
| | |
| |
| 6.84, Аноним (-), 11:34, 05/10/2013 [^] [^^] [^^^] [ответить] [↓] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +1 +/– |
Красиво приложил :).
> нежно портированый из plan9 и допиленый. тyпой шланг не врубается,
Мсье, что вы, как можно, эппл на такие навороты не рассчитывал. Так что будем слушать вопли фанатиков "это не нyжно!!!111".
| | |
| |
| 7.90, arisu (ok), 12:09, 05/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
вот, кстати, только что в списке рассылки Lua пришло:
> I got burned by that particular clang version. At least on 32-bit
> platforms, it makes a mess of compiling something relatively
> straightforward like Lua 5.2. You will have to switch off
> optimization for liolib.c for it to work. | | |
|
| 6.95, Vkni (ok), 19:31, 05/10/2013 [^] [^^] [^^^] [ответить] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
 > тупой шланг не врубается, что
> inline-функция может модифицировать некоторые переменные, передаваемые ей в структуре
Это какая версия компилятора? Т.е. код
struct z_t
{
int a;
int b;
};
inline void f( z_t * z)
{
z.a = 1.0;
}
он откомпилирует неправильно?
| | |
| |
| 7.96, arisu (ok), 19:37, 05/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +1 +/– | |
> Это какая версия компилятора?
3.3.
> он откомпилирует неправильно?
не знаю и проверять лень. там функция несколько сложнее, возвращает тоже структуру и используется в виде funcall(ss)->fld = ss->fld1, при этом ss->fld1 внутри функции меняется. но шланг этого не понимает, и использует старое значение.
p.s. собственно, после раздумий я не уверен, ошибка ли это компилятора, или идиотизм стандарта с очередной «неопределённой последовательностью». но принцип least surprise явно поломан, это раз. и два — если поведение неопределено, то компилятор должен плюнуть предупреждением.
| | |
|
|
|
|
| 3.60, arisu (ok), 14:41, 04/10/2013 [^] [^^] [^^^] [ответить] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– | |
> Предложи более прямой способ сгенерить шейдеры для GPU, например?
предлагаю: унифицировать промежуточную VM для оных GPU, а драйвера пусть при необходимости «докомпиливают» её в родной код. причём поскольку GPU — штуки специфические, то и VM можно сдизайнить соответствующим образом, чтобы на стадии «компиляция в код VM» делалось побольше всего.
но, конечно, наименее костыльный метод — это, я так понимаю, таскать с собой всю механику GCC (которая изначально не предназначена была для подобного использования). или монстра-переростка llvm.
и да: я не уточнил, что подразумеваю использование gcc/llvm именно как jit. это и есть мегаизвращение. что, собственно, доказывает нам Mike Pall со своим LuaJIT2.
| | |
| |
| |
| 5.87, arisu (ok), 11:56, 05/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +1 +/– | |
как я уже сказал — тут две отдельные ветки беседы надо. JIT в одну сторону, компиляцию шэйдеров — в другую.
для шэйдеров и можно, и нужно позвать внешний компилятор. помимо того, что это обезопасит драйвера от ошибок в компиляторе, можно ещё и обновлять раздельно: не надо переустанавливать драйвера, если вышел новый релиз компилятора шэйдеров.
просто в винде создать новый процесс сильно дороже, чем в пингвинусе, вот и занимаются извращениями.
| | |
| |
| |
| 7.93, arisu (ok), 15:10, 05/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +1 +/– | |
> по поводу чего не вижу глобальных отличий от JIT
это потому, что про JIT-ы ты тоже знаешь только три символа, как и про X11.
остальную феерию просто вытер, потому что тут опять «обнять и плакать».
| | |
|
|
|
| 4.111, annulen (ok), 14:37, 07/10/2013 [^] [^^] [^^^] [ответить] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| –1 +/– |
> и да: я не уточнил, что подразумеваю использование gcc/llvm именно как jit.
> это и есть мегаизвращение. что, собственно, доказывает нам Mike Pall со
> своим LuaJIT2.
Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-компиляции. Для Lua LLVM JIT сливает, но не потому что он плохой, а потому что заточен на совсем другие языки.
Кстати, в WebKit яббловцы прикрутили JIT-компиляцию JS с помощью LLVM в качестве четвертого уровня JIT.
| | |
| |
| |
| 6.113, annulen (ok), 15:17, 07/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| –1 +/– |
>> Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-компиляции.
> — алё, Хьюстон, у нас проблемы: воробей!
> — спокойно, уже везём ядерную боеголовку!
Проще взять готовый фронт-енд для С-подобных языков и готовый бэкэнд для JIT, чем городить велосипеды.
| | |
| |
| 7.114, arisu (ok), 15:19, 07/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +1 +/– |
> Проще взять готовый фронт-енд для С-подобных языков и готовый бэкэнд для JIT,
> чем городить велосипеды.
— а пользователь?
— а нам какое дело? купит процессор поновее и ещё 16GB памяти, это его проблемы!
| | |
|
|
|
|
|
|
| 1.15, Аноним (-), 07:21, 04/10/2013 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
угу, для питона, руби, перла, пэхапе - первые будут.
потом всякие тикли, APL и проч и проч - втащат, мб )
было бы прикольно увидеть Erlang OTP - сроднившимся с GCC :P
| | |
| |
| 2.61, arisu (ok), 14:51, 04/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +1 +/– | |
> было бы прикольно увидеть Erlang OTP — сроднившимся с GCC :P
не особо. и вообще, для многих «динамических» языков AOT-компилятор — совсем не лучшее решение, как ни странно. даже если этот AOT-компилятор пытается изобразить из себя JIT.
| | |
|
| 1.17, Vkni (ok), 07:30, 04/10/2013 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| –4 +/– |
Я может быть чего-то не понимаю, но Gentoo вроде бы давно придумали. И компилятся там исходники ровно один раз, а не постоянно, как Jit без кеширования.
| | |
| |
| |
| |
| 4.72, Vkni (ok), 18:16, 04/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
> а память вообще экономит прямо влёт:
> пользователь же каждую наносекунду какой-нибудь шэйдер компилирует!
Меня, если честно, беспокоит вопрос времени - gcc -O2 значительно тормознее gcc -O0. Т.е. фаза оптимизации занимает очень существенное время. А JIT должен быть всё-таки достаточно быстр. Ну, либо придётся ограничиться предкомпиляцией с сохранением результатов (но это и есть вариант Gentoo).
| | |
| |
| 5.73, arisu (ok), 18:24, 04/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +1 +/– |
да и памяти оно тоже кушает. при этом libjit — если выкинуть вливы — весит значительно меньше, работает сильно быстрее и выдаёт достаточно неплохой код. вдобавок имеет интерпретатор для архитектур, где нет кодогенерации.
| | |
| |
| 6.86, Аноним (-), 11:55, 05/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– | |
> да и памяти оно тоже кушает.
В gcc 4.8 вроде как потребление памяти заметно скостили, правда там в основном на LTO вроде непирали.
> при этом libjit — если выкинуть вливы —
Гыгы, действительно, нафиг надо генерить код под GPU? Отдадим шлангу на откуп? :)
> весит значительно меньше, работает сильно быстрее и выдаёт достаточно
> неплохой код. вдобавок имеет интерпретатор для архитектур, где нет кодогенерации.
Звучит довольно вкусно.
| | |
| |
| 7.89, arisu (ok), 12:06, 05/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
>> при этом libjit — если выкинуть вливы —
> Гыгы, действительно, нафиг надо генерить код под GPU?
jit-компилятором? однозначно не надо, jit-ы не для этого совсем придуманы.
>> весит значительно меньше, работает сильно быстрее и выдаёт достаточно
>> неплохой код. вдобавок имеет интерпретатор для архитектур, где нет кодогенерации.
> Звучит довольно вкусно.
оно ещё вкуснее, на самом деле, потому что на вход libjit'у подаётся почти классический SSA. то есть, распределением регистров, уничтожением лишних временных переменных и прочей «низкой» механикой занимается сама libjit. и это действительно удобно.
и ещё там есть плюшки для перекомпиляции уже раз отджитеной функции, при этом с поддержкой многопоточности. то есть, сам компилятор только в одном потоке может работать, но: пока мы упорно занимаемся перекомпиляцией, другие потоки спокойно используют старую версию функции. а потом libjit заменит её на новую. при этом позаботившись о том, чтобы ничего не упало и не сглючило, если какой-то другой поток в это время всё ещё находится в старом варианте.
«из коробки» оно умеет x86, x86_64 и arm. то есть, подавляющее большинство устройств, где может понадобиться, охвачено. да и создание нового бэкэнда не ракетная наука.
| | |
|
|
|
|
|
|
| 1.92, lucentcode (ok), 13:20, 05/10/2013 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
 То, что ребята пошли по пути LLVM не может не радовать. Вот только они опоздали. В LLVM классных плюшек с каждым релизом только прибавляется. И догнать их будет не легко. А поддерживая старый(и зачастую плохо поддерживаемый код на C) - просто не реально.
| | |
| |
| 2.140, Аноним (-), 11:52, 10/10/2013 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– | |
> В LLVM классных плюшек с каждым релизом только прибавляется.
Особенно "классно" с LLVM сношались амдшники, которые добрых 2 года пытались убедить этот крап сгененрить просто валидный код для их GPU. Про оптимизацию кода речь вообще не шла - для этого отдельный довесок присобачили. Который к LLVM вообще никак не относится.
> И догнать их будет не легко. А поддерживая старый(и зачастую
> плохо поддерживаемый код на C) - просто не реально.
Я думаю мсье стоило бы почитать что думают практикующие разработчики о "простоте" работы с clang/llvm. Например, мнение от Vadim Girlin, того который оптимизатор шейдеров написал. Ему проще с нуля оказалось написать это чем с шланговской инфраструктурой бодаться.
| | |
|
|
