форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
Сообщение от opennews (??) on 04-Окт-13, 00:37
Дэвид Малколм (David Malcolm), активный разработчик GCC из компании Red Hat, опубликовал (http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00228.html) прототип библиотеки libgccjit.so с реализацией встраиваемого в приложения JIT-компилятора, использующего GCC в качестве бэкенда. Данная библиотека может быть динамически связана с интерпретаторами байткода и другими программами, которым необходима генерации машинного кода на лету, во время выполнения. Идея проекта состоит в том, что GCC собирается в форме позиционно-независимого кода (http://ru.wikipedia.org/wiki/%D0%9C%D0%B...), который присоединяется к библиотеке libgccjit.so, что позволяет обеспечить возможность выполнения GCC в одном процессе с генерируемым машинным кодом. Инициирование компиляции и выполнения откомпилированных на лету блоков кода производится приложением при помощи специально предоставленного библиотекой API. Первый прототип проекта поддерживает JIT-компиляцию кода на языке Си, но уже началась подготовка биндинга для языка Python. Другим интересным проектом, является опубликованный (http://gcc.gnu.org/ml/gcc/2013-09/msg00235.html) разработчиками из компании Samsung модифицированный вариант GCC с интегрированной поддержкой стандарта OpenACC 1.0 (http://ru.wikipedia.org/wiki/OpenACC). Указанный вариант GCC даёт возможность сформировать исполняемый файл, позволяющий в процессе работы программы вынести выполнение некоторых вычислительных операций на плечи GPU. URL: http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00228.html Новость: https://www.opennet.ru/opennews/art.shtml?num=38075
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по ответам | RSS]

	1. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	–5 +/–
	Сообщение от Аноним (??) on 04-Окт-13, 00:37
	Чем оно лучше LLVM?
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+4 +/–
	Сообщение от ssy on 04-Окт-13, 00:37
	Скоро окажется, что gpu работает наравне с cpu и последний можно убрать. Потом окажется, что gpu можно разгрузить, добавив cpu. Ну вы поняли.
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+12 +/–
	Сообщение от pavlinux (ok) on 04-Окт-13, 00:45
	Килотонны петабайт исходников не надо будет переписывать.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	4. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+15 +/–
	Сообщение от Хрен с горы on 04-Окт-13, 00:46
	Выше скорость генерируемого кода, поддерживает большое количество платформ, нет зависимости от одной компании, свободная лицензия.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	5. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+4 +/–
	Сообщение от pavlinux (ok) on 04-Окт-13, 00:47
	> Скоро окажется, что gpu работает наравне с cpu ... Еще лет 7-8 назад один из разрабов Nvidia вывалил на сайте developer.nvidia.com, что они запускали ядро Linux на GeForce, вроде 6800GT. Пост исчез в течении двух дней, разраба никто больше не слышал.  :) Чуть раньше, когда CUDA и OpenCL в планах даже не было, один чувак, реализовал функции сортировки, сравнения строк на Жыфорсе. Его сайт жил дольше, но не обновлялся ни разу.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	6. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от Аноним (??) on 04-Окт-13, 00:52
	Не в начале апреля пост был?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от pavlinux (ok) on 04-Окт-13, 00:56
	Симшьно, ща уписаюсь http://www.cs.utah.edu/~wbsun/gpustore.pdf
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	8. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от vitalif (ok) on 04-Окт-13, 00:58
	А ещё был более-менее реальный proof of concept червя, живущего исключительно в памяти GPU и в ROM'е broadcom'овской сетевухи (она там тоже такая типа вся программируемая), и слущающего трафик.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	9. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+2 +/–
	Сообщение от rshadow (ok) on 04-Окт-13, 01:38
	Странная эта борьба за новые языки и возможности. Все время пытаются сделать лазерный скальпель, когда вогруг все пилят только деревья. Надо бы культуру программирования и технологии в массы подтянуть, а не переизобретать очередной велосипед на очередном языке.
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+1 +/–
	Сообщение от pavlinux (ok) on 04-Окт-13, 01:44
	Кстати, на Опеннете новость была.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	12. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от Аноним (??) on 04-Окт-13, 03:32
	Речь скорее идет о изобретении инструментов переноса старого кода и инструментов в новые условия. Что с того, что новые условия это не лесопилка, а что то потоньше? Уровень среднего программера остается неизменным.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	13. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от jOKer (ok) on 04-Окт-13, 03:53
	>но уже началась подготовка биндинга для языка Python. Отличненько, - горю желанием заценить!
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	14. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от arisu (ok) on 04-Окт-13, 04:33
	забавно, конечно, но редкостные извращенцы. что этот, что llvm-щики.
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	15. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от Аноним (??) on 04-Окт-13, 07:21
	угу, для питона, руби, перла, пэхапе - первые будут. потом всякие тикли, APL и проч и проч - втащат, мб ) было бы прикольно увидеть Erlang OTP - сроднившимся с GCC :P
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Аноним (??) on 04-Окт-13, 07:22
	На миллионyю по счету просьбу засветить свой код, который лучше, будет традиционное мужественное самоотверженное молчание ? Часто незнакомых людей "редкостными извращенцами" в лицо называешь?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	17. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	–4 +/–
	Сообщение от Vkni (ok) on 04-Окт-13, 07:30
	Я может быть чего-то не понимаю, но Gentoo вроде бы давно придумали. И компилятся там исходники ровно один раз, а не постоянно, как Jit без кеширования.
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	18. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	–19 +/–
	Сообщение от Аноним (??) on 04-Окт-13, 07:57
	в общем, если поскипать бред, то получается, что преимуществ-то и нет. Сейчас все новые компиляторы, трансляторы и т.п. или пишутся с нуля, или используют LLVM в качестве бэкенда, а GCC с его обфусцированной архитектурой (привет параноику Столлману) никому нафиг не нужен :)
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	19. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+3 +/–
	Сообщение от Аноним (??) on 04-Окт-13, 08:17
	> никому нафиг не нужен :) Ну да, кроме вон той толпени корпорасов типа IBM, интелов и еще 100500 всяких, билдующих им себе линух для своих железяк.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	21. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от Аноним (??) on 04-Окт-13, 08:39
	Вы вообще нихрена не понимаете. И гентушники тут ни о чем. Что есть у гентушников для того чтобы, например, вгрузить шейдер в GPU, предварительно скомпилив его, ась? И да, драйверу GPU например несколько не комильфо стартовать новые процессы с компилером. Функцию библы позвать - еще куда ни шло. Ну а программа (OpenGL/OpenCL/...) не может заранее знать какой там у вас GPU и как под него шейдеры генерить. Поэтому все что оно может - попросить "а скомпильте мне это и запустите", ну а дальше уже драйвер и бэкэнд кодогенерации будут разбираться как "это" превратить в команды понимаемые "вон тем" GPU, который в системе есть. Аналогично - везде где надо скрипты или байткод выполнять, они тормозят если их интерпретировать, т.к. полезная логика всегда сильно разбавлена логикой интерпретатора. А если все заранее в нативный машинный код перегнать и выполнять его - можно сочетать достоинства компиляторов и интерпретаторов. От интерпретаторов - не надо заранее знать какая платформа + нет видимой програмеру фазы компиляции под каждую конкретную платформу. От компиляторов - скорость выполнения типичная для компилированного кода. Просто фазу окончательной компиляции в нативный код снесли на юзеря. Это чем-то похожа на гентушников :))) но совсем не в том виде каком они себе это представляли.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	22. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Аноним (??) on 04-Окт-13, 08:42
	> забавно, конечно, но редкостные извращенцы. что этот, что llvm-щики. Предложи более прямой способ сгенерить шейдеры для GPU, например? Как ты понимаешь, заранее вообще неизвестно что там у юзеря: ати, нвидия, интел или вообще какой-нить ARM. Поэтому программа явно не может таскать с собой для этого предкомпилированный код.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	24. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+1 +/–
	Сообщение от BratSinot (ok) on 04-Окт-13, 09:03
	Вам повторить про более лучшую оптимизацию и большее количество поддерживаемых платформ/архитектур?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	26. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+1 +/–
	Сообщение от Аноним (??) on 04-Окт-13, 09:17
	https://www.opennet.ru/opennews/art.shtml?num=23833 nVidia Fermi сможет выполнять Linux https://www.opennet.ru/opennews/art.shtml?num=30484 Проект KGPU позволяет задействовать GPU для выполнения фрагментов кода ядра Linux
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	30. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от 123 (??) on 04-Окт-13, 09:54
	Да ты что, а это что по твоему? http://www-03.ibm.com/software/products/us/en/ccompfami/
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	31. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	–11 +/–
	Сообщение от Человек (??) on 04-Окт-13, 09:55
	А почему Oracle Solaris Studio свой компилятор включает ? Зачем Intel свой компилятор продаёт ? Зачем AMD пилит свой форк Open64 ? Зачем IBM продаёт XL ? Зачем The Portland Group продаёт свой компилятор ? Это великие IT-компании, у которых достаточно компетенции для реализации своих собственных компиляторов. У Red Hat такой компетенции нет и они используют GCC. GCC нужен ТОЛЬКО для компиляции ядра Linux и другого ПО, которое использует костыли от GCC (его очень мало). В ядре Linux содержатся куча костылей. Эти костыли используют костыли из GCC. Вот и всё. Apple выкинула GCC и FreeBSD тоже. Реально GCC НЕ НУЖЕН !
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	35. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от Аноним (??) on 04-Окт-13, 11:02
	Это завязано на CUDA и блободрайвере, что для ядра сильно-сильно не айс. Вот если будет VAAPI и nouveau (radeon), то тогда да.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	36. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	–2 +/–
	Сообщение от zhenya_k on 04-Окт-13, 11:11
	За вами тоже уже выехали.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	37. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+2 +/–
	Сообщение от анонимус (??) on 04-Окт-13, 11:17
	Это никогда не случится :) Вы не особо представляете как вообще GPU работает. Для некоторых алгоритмов намного быстрее, а для некоторых наоборот намного медленнее. А вот решения AMD CPU + GPU - APU вполне жизнеспособны, как в свое время CPU + FPU.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	39. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+1 +/–
	Сообщение от Аноним (??) on 04-Окт-13, 11:27
	Лучше спросите зачем все это покупают. И кстати компилятор из Solaris Studio жуткое уе.ище.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	40. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от Аноним (??) on 04-Окт-13, 11:31
	Извинитесь.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	41. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от Аноним (??) on 04-Окт-13, 11:43
	Ну да. Давайте теперь каждую программу тестировать в разных компиляторах вместо одного и собирать не только для разной архитектуры, но и производителя, ура товарищи, ура! А заодно напомните, кто реально для работы на ПК(а не узкоспециализированном железе одной фирмы) будет это делать, заранее спасибо.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	42. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+1 +/–
	Сообщение от Аноним (??) on 04-Окт-13, 11:54
	> CUDA... VAAPI и nouveau (radeon) Какие еще слова знаешь?
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	43. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+2 +/–
	Сообщение от Аноним (??) on 04-Окт-13, 12:03
	> Да ты что, а это что по твоему? http://www-03.ibm.com/software/products/us/en/ccompfami/ Понятия не имею что это. Зато догадываюсь чем они собирают ядро линя и софт под свой любимый power, например. Наверняка это gcc, да :).
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	45. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+9 +/–
	Сообщение от Аноним (??) on 04-Окт-13, 12:28
	> А почему 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Н ! Кому? Проприерасам и их подстилкам? Окей, пусть идут на...й, я не возражаю :).
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	46. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	–1 +/–
	Сообщение от YetAnotherOnanym (ok) on 04-Окт-13, 12:31
	> Килотонны петабайт исходников не надо будет переписывать. Правильно написанный исходник не нужно бывает переписывать.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	50. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+4 +/–
	Сообщение от Аноним (??) on 04-Окт-13, 12:56
	> Правильно написанный исходник не нужно бывает переписывать. Да, в случае сферического коня в идеальном вакууме... (с) анекдот :)
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	56. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	–2 +/–
	Сообщение от Аноним (??) on 04-Окт-13, 13:58
	Нет, в случае нерукожопого программиста. Переход FreeBSD на clang показал что таких, к счастью, большинство - clang'ом не собиралось не больше десятка процентов портов, из них большая часть исправлялась добавлением пропущенного #include (что, кстати, значит что в gcc'шной libstdc++ инклудится лишнее, если она это жрала), с USE_GCC остались единицы с реальными gcc'измами.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	57. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+2 +/–
	Сообщение от Аноним (??) on 04-Окт-13, 14:02
	> Ну да. Давайте теперь каждую программу тестировать в разных компиляторах вместо одного > и собирать не только для разной архитектуры, но и производителя, ура > товарищи, ура! Не "давайте", а все нормальные люди так и делали всегда, потому что это повышает шанс ловли ошибок и несовместимостей. Посмотрите хотя бы travis ci, оно по умолчанию давно поддерживает как минимум gcc и clang. Но куда GNU'шным проприетарщикам это понять - у них одна архитектура - бyбунту.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	58. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Аноним (??) on 04-Окт-13, 14:05
	>> забавно, конечно, но редкостные извращенцы. что этот, что llvm-щики. > Предложи более прямой способ сгенерить шейдеры для GPU, например? Как ты понимаешь, > заранее вообще неизвестно что там у юзеря: ати, нвидия, интел или > вообще какой-нить ARM. Поэтому программа явно не может таскать с собой > для этого предкомпилированный код. Вы прям так спрашиваете как будто arisu разбирается в компьютерах и не просто так брякнул.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	59. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+2 +/–
	Сообщение от arisu (ok) on 04-Окт-13, 14:36
	> На миллионyю по счету просьбу засветить свой код, который лучше, будет традиционное > мужественное самоотверженное молчание ? Часто незнакомых людей «редкостными извращенцами» > в лицо называешь? проси на здоровье, за спрос денег не берут.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	60. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от arisu (ok) on 04-Окт-13, 14:41
	> Предложи более прямой способ сгенерить шейдеры для GPU, например? предлагаю: унифицировать промежуточную VM для оных GPU, а драйвера пусть при необходимости «докомпиливают» её в родной код. причём поскольку GPU — штуки специфические, то и VM можно сдизайнить соответствующим образом, чтобы на стадии «компиляция в код VM» делалось побольше всего. но, конечно, наименее костыльный метод — это, я так понимаю, таскать с собой всю механику GCC (которая изначально не предназначена была для подобного использования). или монстра-переростка llvm. и да: я не уточнил, что подразумеваю использование gcc/llvm именно как jit. это и есть мегаизвращение. что, собственно, доказывает нам Mike Pall со своим LuaJIT2.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	61. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от arisu (ok) on 04-Окт-13, 14:51
	> было бы прикольно увидеть Erlang OTP — сроднившимся с GCC :P не особо. и вообще, для многих «динамических» языков AOT-компилятор — совсем не лучшее решение, как ни странно. даже если этот AOT-компилятор пытается изобразить из себя JIT.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	64. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от arisu (ok) on 04-Окт-13, 15:01
	> И да, драйверу GPU например несколько не комильфо стартовать новые процессы > с компилером. Функцию библы позвать — еще куда ни шло. действительно, то ли дело — прямо в драйвер вкорячить немеряных размеров библиотеку компилятора. это же так секурно, а память вообще экономит прямо влёт: пользователь же каждую наносекунду какой-нибудь шэйдер компилирует! намного разумней как раз отдельные процессы, стандартизованый язык и универсальный способ вызова компилятора. и не нужно таскать с собой костыли: большинство софта будет вызывать оный компилятор при установке, заранее собирая шейдеры под GPU, который на борту. и оставшаяся небольшая часть — вызывать по мере необходимости. that's all, folks! > Аналогично — везде где надо скрипты или байткод выполнять, они тормозят если > их интерпретировать, т.к. полезная логика всегда сильно разбавлена логикой интерпретатора. > А если все заранее в нативный машинный код перегнать и выполнять > его — можно сочетать достоинства компиляторов и интерпретаторов. От интерпретаторов — > не надо заранее знать какая платформа + нет видимой програмеру фазы > компиляции под каждую конкретную платформу. От компиляторов — скорость выполнения типичная > для компилированного кода. Просто фазу окончательной компиляции в нативный код снесли > на юзеря. Это чем-то похожа на гентушников :))) но совсем не > в том виде каком они себе это представляли. а этот пассаж вообще офигительно смешон. сразу видно человека, который проблематику JIT-компиляторов для «динамических» языков не понимает вообще. максимум — что-то там слышал краем уха, и уверен, что AOT-компилятор завсегда лучше JIT в любой области. и что полновесный AOT-компилятор типа GCC — это такая мелочь, оверхэд от которой вообще не стоит упоминания. ещё раз отправляю тебя внимательно смотреть на LuaJIT2. и на то, как происходит кодогенерация в GCC и сколько все его фазы весят (как в плане памяти, так и в плане скорости). это для начала.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	65. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+4 +/–
	Сообщение от Пиу (ok) on 04-Окт-13, 15:45
	напомни, сколько шлангу пришлось из-за этого поддерживать гнутых/гцц-шных расширений?
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	66. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+3 +/–
	Сообщение от arisu (ok) on 04-Окт-13, 15:55
	шланг с его хроническими болячками намного проще объявить неподдерживаемым и не заморачиваться. оно до сих пор в оптимизации inline-функций косячит, ну нафиг такие грабли.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	67. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+2 +/–
	Сообщение от arisu (ok) on 04-Окт-13, 15:57
	> Вам повторить про более лучшую оптимизацию и большее количество поддерживаемых платформ/архитектур? бессмысленно, оно в этом ничего не понимает. достаточно пассажа про «обфусцированую архитектуру», чтобы это понять.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	68. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+4 +/–
	Сообщение от arisu (ok) on 04-Окт-13, 16:06
	> напомни, сколько шлангу пришлось из-за этого поддерживать гнутых/гцц-шных расширений? при этом две самые полезные фичи так и не поддерживает: nested functions и statement expressions. оно понятно, что хардкорные фанаты тверды в своём принципе «что было хорошо для наших дедов и отцов — то хорошо и для нас», но эти две фичи, как я уже писал, без мегаусложнения компилятора дают приятные бонусы. например, удобные однострочные макросы min/max, вычисляющие аргументы ровно один раз, или нечто вроде лямбд для тех же qsort()/bsearch(), которые (вроде-лямбды) могут быть объявлены прямо параметром и напрямую обращаться к переменным родительской функции. но это, конечно, не Ъ.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	69. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+2 +/–
	Сообщение от Клыкастый (ok) on 04-Окт-13, 16:17
	"gcc не нужен"... это... сильно. таких жирнючих троллей ещё не было. моё почтение.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	70. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	–1 +/–
	Сообщение от Аноним (??) on 04-Окт-13, 16:45
	Wiki всем доступно, можешь и ты просветиться :)
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	72. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Vkni (ok) on 04-Окт-13, 18:16
	> а память вообще экономит прямо влёт: > пользователь же каждую наносекунду какой-нибудь шэйдер компилирует! Меня, если честно, беспокоит вопрос времени - gcc -O2 значительно тормознее gcc -O0. Т.е. фаза оптимизации занимает очень существенное время. А JIT должен быть всё-таки достаточно быстр. Ну, либо придётся ограничиться предкомпиляцией с сохранением результатов (но это и есть вариант Gentoo).
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	73. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от arisu (ok) on 04-Окт-13, 18:24
	да и памяти оно тоже кушает. при этом libjit — если выкинуть вливы — весит значительно меньше, работает сильно быстрее и выдаёт достаточно неплохой код. вдобавок имеет интерпретатор для архитектур, где нет кодогенерации.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	74. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+1 +/–
	Сообщение от Vkni (ok) on 04-Окт-13, 18:25
	> А почему Oracle Solaris Studio свой компилятор включает ? Исторические причины + значительно лучшая кодогенерация под SPARC. Впрочем, есть проект гибрида GCC и SunCC. К сожалению, компилятор Oracle последнее время развивается ужасно и c++11 ещё не поддерживает от слова совсем. > Зачем Intel свой компилятор продаёт ? Для лучшей оптимизации под свои процессоры. Относительно недавно был даже скандал, связанный с тем, что в сторонних процессорах эти компиляторы не включали возможные оптимизации. > Зачем AMD пилит свой форк Open64 ? См. выше - на icc далеко не уедешь. Про остальных не знаю. > Это великие IT-компании, у которых достаточно компетенции для реализации своих собственных > компиляторов. У Red Hat такой компетенции нет и они используют GCC. Вообще-то, разработчики C++ тестируют перспективные фичи, вставляя их в код GCC. Скажем, непрошедшие в стандарт Concepts были реализованы для GCC. > GCC нужен ТОЛЬКО для компиляции ядра Linux и другого ПО, которое использует > костыли от GCC (его очень мало). Это компилятор по-умолчанию в Linux'ах. Т.е. на данный момент это основной C/C++ компилятор.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	75. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+3 +/–
	Сообщение от arisu (ok) on 04-Окт-13, 18:34
	> Это компилятор по-умолчанию в Linux'ах. Т.е. на данный момент это основной C/C++ > компилятор. более того: это компилятор, вероятность наличия которого на какой-нибудь хитрой системе (или возможности поставить порт) очень близка к единице. поэтому имеет смысл писать код так, чтобы его мог прожевать gcc, а остальными компиляторами заморачиваться только по мере неленивости.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	76. "Основанные на GCC проекты JIT-компилятора и расширения,..."	–2 +/–
	Сообщение от Аноним (??) on 04-Окт-13, 19:21
	не мешай ему дилетанствовать c самовлюбленным апломбом, вон уже чуть ниже поток полился про "ощущения чуйств" на тему GCC. Замени GCC и LLVM на Коллайдер и систему жизнеобеспечения автономного модуля на Марсе, впрочем и митохондрии подойдут - суть не поменяется. Костьми ляжет, но ни слова не дождешься о конкретных проверяемых сущностях.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	77. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+6 +/–
	Сообщение от arisu (ok) on 04-Окт-13, 19:29
	(пожимает плечами) конкретная сущность — это намертво зависающий движок регулярок, нежно портированый из plan9 и допиленый. тупой шланг не врубается, что inline-функция может модифицировать некоторые переменные, передаваемые ей в структуре (хотя никакого const там нет), поэтому сначала переменную где-то кэширует, а потом использует её старое значение. в итоге получается бесконечный цикл вида «jmp $». чего лично я от компилятора такого возраста никак не ожидал и был несколько в офигее, когда софтина подвисла, слопав весь процессор. но я понимаю, что для тебя «я наступил на баг в компиляторе» — ситуация вообще невозможная, потому что твой «приветмир» без ворнингов вообще не собирается. какие уж там баги компилятора…
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	78. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от Аноним (??) on 04-Окт-13, 20:34
	Использовать gcc для jit какая-то нелепость при наличии llvm.
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	79. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+2 +/–
	Сообщение от Аноним (??) on 05-Окт-13, 09:29
	> Нет, в случае нерукожопого программиста. Наверное это был сам Юрий Нежопорукий. > Переход FreeBSD на clang показал что ...что они х#$рят на своей волне и ни с кем не считаются, ставя свои лицензионные бзики выше получаемого на выходе результата.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	80. "Основанные на GCC проекты JIT-компилятора и расширения,..."	–1 +/–
	Сообщение от arisu (ok) on 05-Окт-13, 09:35
	> Использовать gcc для jit какая-то нелепость при наличии llvm. не большая, чем использовать для этого llvm.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	81. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+3 +/–
	Сообщение от Аноним (??) on 05-Окт-13, 09:57
	> бессмысленно, оно в этом ничего не понимает. достаточно пассажа про «обфусцированую > архитектуру», чтобы это понять. Что-то НеОбфусцированная архитектура LLVM оказалась настолько не готова к тому что на этой планете бывает VLIW, что АМДшники 2 года долбались чтобы получить на выходе хотя-бы просто технически валидный код. Итого? Два года долботни разработчиков с нулевым user-visible результатом. Потом приходит некий Vadim Girlin - "ребята, да вы офигели - два года въ...ть без результата видимого юзерям?" и за весьма короткий срок фиксит подобный булшит в отдельном довеске, который парсит код и оптимизирует его. Что характерно - оказалось проще сделать сие вообще без услуг LLVM, отдельной сущностью, так что этот бэкэнд работает и для LLVM и для местечкового кодогенератора. Такая супер-архитектура и success story от ее внедрежа...
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	82. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от Аноним (??) on 05-Окт-13, 09:59
	> Вот если будет VAAPI И как именно апи для декодирования видео относится к вычислениям на GPU? :)
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	83. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+2 +/–
	Сообщение от arisu (ok) on 05-Окт-13, 10:02
	да тут начинать надо с того, что никакой «обфусцированой архитектуры» в gcc нет: надо просто иметь рабочие мозги и понимать предметную область. llvm же вполне хорош — для своих применений. правда, там с дизайном совсем не радуга с поняшами, но и это тут обсуждать смысла нет: фанбои тупые, а те, кому интересно состояние дел, и так знают.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	84. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от Аноним (??) on 05-Окт-13, 11:34
	Красиво приложил :). > нежно портированый из plan9 и допиленый. тyпой шланг не врубается, Мсье, что вы, как можно, эппл на такие навороты не рассчитывал. Так что будем слушать вопли фанатиков "это не нyжно!!!111".
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	85. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Аноним (??) on 05-Окт-13, 11:50
	> предлагаю: унифицировать промежуточную VM для оных GPU, Уже была попытка, кстати. Называлось сие TGSI, см. http://people.freedesktop.org/~csimpson/gallium-docs/tgsi.html - и оно местами таки юзается. Но на общие вычисления не особо заточено, тому что сейчас в GPU не очень соответствует, и вообще имеет кучу грабель и все на это подзабили. К тому же еще парсить код шейдеров кто-то должен, в том числе и выислительный, а OpenCL уже достаточно приличный кусок от си. Собственно из каких-то таких соображений LLVM нынче и юзают нынче: парсер и генератор кода. > то и VM можно сдизайнить соответствующим образом, чтобы на стадии «компиляция > в код VM» делалось побольше всего. Уже было и уже частично пострадало за свою специфичность, т.к. TGSI был слишком ориентирован на графику, а на GPGPU - как-то не особо. А тут до народа дошло что раз есть столько числокрушилок - хорошо бы на них не только графику считать :). Ну вот народ и возится теперь кто с чем. В конечном итоге это нынче выглядит так: на вход дается сорц шейдера или вычислительного кернела а как оно там его перегонит сие в нативный код GPU - уже проблемы драйвера. При этом виртуальный набор команд не навязывается, там могут быть грабли еще и в том что этот набор менее фичаст чем свойства конкретного GPU который умеет больше нежели это. При компиляции из сорца такая проблема не возникает ессно. А вот внутрях там уже кто как делает. В открытых дровах интел пилит свою собственную реализацию opencl, амдшники поюзали некоторые части gallium и LLVM как генератор кода, etc. Что там у нуво - хрен их знает. Проприерасы IIRC целиком запилили с нуля свои реализации. > но, конечно, наименее костыльный метод — это, я так понимаю, таскать с > собой всю механику GCC (которая изначально не предназначена была для подобного > использования). или монстра-переростка llvm. Сдается мне что gcc не сильно меньше LLVM будет в этом плане. Ну и да, gcc на такое изначально никто вообще не рассчитывал, хотя то что его таки прикрутили и для этого, да еще довольно быстро - внушает. Яблочно-бздoтные фанаты бы оборались тут уже если б их фетиш с такой скоростью кто-то допиливал под разные задачи. > и да: я не уточнил, что подразумеваю использование gcc/llvm именно как jit. > это и есть мегаизвращение. что, собственно, доказывает нам Mike Pall со > своим LuaJIT2. LuaJIT это конечно круто и замечательно, но шейдеры пишутся на чем-то сиподобном, а OpenCL по сути специфичный диалект си. Так что да, кроме JIT надо бы еще и парсер этого самого си-подобного синтаксиса. Для OpenCL его целиком фигачить не вломак оказалось интелу, АМД заломало и они взяли из шланга. Почему не GCC? Ну... они уже 2 года долбутся с этим, 2 года назад сабжа не было :)
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	86. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Аноним (??) on 05-Окт-13, 11:55
	> да и памяти оно тоже кушает. В gcc 4.8 вроде как потребление памяти заметно скостили, правда там в основном на LTO вроде непирали. > при этом libjit — если выкинуть вливы — Гыгы, действительно, нафиг надо генерить код под GPU? Отдадим шлангу на откуп? :) > весит значительно меньше, работает сильно быстрее и выдаёт достаточно > неплохой код. вдобавок имеет интерпретатор для архитектур, где нет кодогенерации. Звучит довольно вкусно.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	87. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от arisu (ok) on 05-Окт-13, 11:56
	как я уже сказал — тут две отдельные ветки беседы надо. JIT в одну сторону, компиляцию шэйдеров — в другую. для шэйдеров и можно, и нужно позвать внешний компилятор. помимо того, что это обезопасит драйвера от ошибок в компиляторе, можно ещё и обновлять раздельно: не надо переустанавливать драйвера, если вышел новый релиз компилятора шэйдеров. просто в винде создать новый процесс сильно дороже, чем в пингвинусе, вот и занимаются извращениями.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	89. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от arisu (ok) on 05-Окт-13, 12:06
	>> при этом libjit — если выкинуть вливы — > Гыгы, действительно, нафиг надо генерить код под GPU? jit-компилятором? однозначно не надо, jit-ы не для этого совсем придуманы. >> весит значительно меньше, работает сильно быстрее и выдаёт достаточно >> неплохой код. вдобавок имеет интерпретатор для архитектур, где нет кодогенерации. > Звучит довольно вкусно. оно ещё вкуснее, на самом деле, потому что на вход libjit'у подаётся почти классический SSA. то есть, распределением регистров, уничтожением лишних временных переменных и прочей «низкой» механикой занимается сама libjit. и это действительно удобно. и ещё там есть плюшки для перекомпиляции уже раз отджитеной функции, при этом с поддержкой многопоточности. то есть, сам компилятор только в одном потоке может работать, но: пока мы упорно занимаемся перекомпиляцией, другие потоки спокойно используют старую версию функции. а потом libjit заменит её на новую. при этом позаботившись о том, чтобы ничего не упало и не сглючило, если какой-то другой поток в это время всё ещё находится в старом варианте. «из коробки» оно умеет x86, x86_64 и arm. то есть, подавляющее большинство устройств, где может понадобиться, охвачено. да и создание нового бэкэнда не ракетная наука.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	90. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от arisu (ok) on 05-Окт-13, 12:09
	вот, кстати, только что в списке рассылки 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.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	91. "Основанные на GCC проекты JIT-компилятора и расширения,..."	–1 +/–
	Сообщение от Аноним (??) on 05-Окт-13, 13:18
	> как я уже сказал — тут две отдельные ветки беседы надо. JIT > в одну сторону, компиляцию шэйдеров — в другую. Компиляция шейдеров во время выполнения происходит, по поводу чего не вижу глобальных отличий от JIT в плане логики действа, если честно. Единственное чем оно так глобально отличается - сгенеренный код потом не на системном проце выполняется а отправится в GPU. > для шэйдеров и можно, и нужно позвать внешний компилятор. Не, спасибочки, еще не хватало чтобы при запуске какойнить игрушки 100500 внешних процессов пахало. Нафиг-нафиг. > помимо того, что это обезопасит драйвера от ошибок в компиляторе, Программа все-равно не сможет корректно работать если шейдер или CLный кернель не скомпилился. Если компилер даже совсем навернется где-то в прога -> GL/CL либы -> компилер - да и болт с ним. Нехай чинят, юзери лишний раз прессанут разработчиков чтобы обезглючили эту хрень. > можно ещё и обновлять раздельно: не надо переустанавливать драйвера, > если вышел новый релиз компилятора шэйдеров. Компилятор шейдеров не имеет самоценности как отдельная сущность в отрыве от драйверов, которые позволяют то что получилось в GPU запихнуть и запустить. > просто в винде создать новый процесс сильно дороже, чем в пингвинусе, вот > и занимаются извращениями. А при чем тут вообще винда? Амдшники в открытом драйвере юзанули, с аргументом что там парсер есть и кодогенератор какой-никакой.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	92. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от lucentcode (ok) on 05-Окт-13, 13:20
	То, что ребята пошли по пути LLVM не может не радовать. Вот только они опоздали. В LLVM классных плюшек с каждым релизом только прибавляется. И догнать их будет не легко. А поддерживая старый(и зачастую плохо поддерживаемый код на C) - просто не реально.
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	93. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от arisu (ok) on 05-Окт-13, 15:10
	> по поводу чего не вижу глобальных отличий от JIT это потому, что про JIT-ы ты тоже знаешь только три символа, как и про X11. остальную феерию просто вытер, потому что тут опять «обнять и плакать».
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	95. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Vkni (ok) on 05-Окт-13, 19:31
	> тупой шланг не врубается, что > inline-функция может модифицировать некоторые переменные, передаваемые ей в структуре Это какая версия компилятора? Т.е. код struct z_t {     int a;     int b; }; inline void f( z_t * z) {     z.a = 1.0; } он откомпилирует неправильно?
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	96. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от arisu (ok) on 05-Окт-13, 19:37
	> Это какая версия компилятора? 3.3. > он откомпилирует неправильно? не знаю и проверять лень. там функция несколько сложнее, возвращает тоже структуру и используется в виде funcall(ss)->fld = ss->fld1, при этом ss->fld1 внутри функции меняется. но шланг этого не понимает, и использует старое значение. p.s. собственно, после раздумий я не уверен, ошибка ли это компилятора, или идиотизм стандарта с очередной «неопределённой последовательностью». но принцип least surprise явно поломан, это раз. и два — если поведение неопределено, то компилятор должен плюнуть предупреждением.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	97. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	–2 +/–
	Сообщение от хрюкотающий зелюк on 06-Окт-13, 23:27
	> но уже началась подготовка биндинга для языка Python а вот это уже интересно
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	100. "Основанные на GCC проекты JIT-компилятора и расширения,..."	–1 +/–
	Сообщение от linux must _RIP_ on 07-Окт-13, 11:52
	а так же дают постоянный исполняемый стек, что открывает простор для написания экслойтов :-)
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	101. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	–2 +/–
	Сообщение от linux must _RIP_ on 07-Окт-13, 11:54
	> ...что они х#$рят на своей волне и ни с кем не считаются, > ставя свои лицензионные бзики выше получаемого на выходе результата. это вы о большинстве линуксоидных программистов? которые слов c-std .., POSIX, SUS боятся как огня ?:)
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	104. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от arisu (ok) on 07-Окт-13, 11:59
	пшёл вон, мразь.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	105. "Основанные на GCC проекты JIT-компилятора и расширения,..."	–2 +/–
	Сообщение от annulen (ok) on 07-Окт-13, 13:04
	>при этом две самые полезные фичи так и не поддерживает: nested functions и statement expressions. Для кода, не соответствующего стандарту, не может быть оправданий. И пофиг, гнутые это расширения, или мелкософтовские.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	106. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	–2 +/–
	Сообщение от annulen (ok) on 07-Окт-13, 13:05
	>> никому нафиг не нужен :) > Ну да, кроме вон той толпени корпорасов типа IBM, интелов и еще > 100500 всяких, билдующих им себе линух для своих железяк. Тем временем парни из IBM уже запилили LLVM и Clang для Power и System Z.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	107. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+3 +/–
	Сообщение от arisu (ok) on 07-Окт-13, 13:17
	мне как-то совершенно плевать на идиотские стандарты. стандарт на си особенно идиотский, с его «поведение неопределено» и принципиальным невключением удобных вещей. меня волнует не чтобы стандарту было хорошо, а чтобы мне было удобно. поэтому я использовал и буду использовать gcc-шные атрибуты (в частности, любимые constructor, destructor, cleanup), вложеные функции и выражения-операторы. в отличие от стандартов, которые придуманы космическими академиками для облегчения жизни компилерописателям, эти расширения были придуманы программистами для облегчения жизни себе и другим программистам. а также реализованы в самом распространённом компиляторе, который портировали на огромное количество систем. поэтому они — стандарт де-факто. кто не согласен — тот может ними не пользоваться, его право.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	108. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 07-Окт-13, 14:08
	> а так же дают постоянный исполняемый стек, что открывает простор для написания > экслойтов :-) Пошёл gcc патчить, м*азь.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	109. "Основанные на GCC проекты JIT-компилятора и расширения,..."	–1 +/–
	Сообщение от annulen (ok) on 07-Окт-13, 14:33
	>> Это какая версия компилятора? > 3.3. >> он откомпилирует неправильно? > не знаю и проверять лень. там функция несколько сложнее, возвращает тоже структуру > и используется в виде funcall(ss)->fld = ss->fld1, при этом ss->fld1 внутри > функции меняется. но шланг этого не понимает, и использует старое значение. Выкладывай отпрепроцессенный файл и опции компиляции, я проверю.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	111. "Основанные на GCC проекты JIT-компилятора и расширения,..."	–1 +/–
	Сообщение от annulen (ok) on 07-Окт-13, 14:37
	> и да: я не уточнил, что подразумеваю использование gcc/llvm именно как jit. > это и есть мегаизвращение. что, собственно, доказывает нам Mike Pall со > своим LuaJIT2. Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-компиляции. Для Lua LLVM JIT сливает, но не потому что он плохой, а потому что заточен на совсем другие языки. Кстати, в WebKit яббловцы прикрутили JIT-компиляцию JS с помощью LLVM в качестве четвертого уровня JIT.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	112. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от arisu (ok) on 07-Окт-13, 14:50
	> Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-компиляции. — алё, Хьюстон, у нас проблемы: воробей! — спокойно, уже везём ядерную боеголовку! > Для Lua LLVM JIT сливает, но не потому что он плохой, > а потому что заточен на совсем другие языки. тут вот в списке рассылки LuaJIT забавное пролетело: транслятор байт-кода JVM в байт-код LuaJIT. первая версия — в общем-то PoC — показала (на микротестах, конечно) результаты кое-где получше хотспота, а кое-где ненамного хуже. ну, и кое-где таки хуже — потому что автор транслятора сделал некоторые вещи неправильно, на что СуперМайк ему указал. про потребление памяти лучше умолчу вообще, чтобы у жавистов падучая не началась. это я к чему? к тому, что с джитингом «статически типизированых» языков LuaJIT2 справляется тоже весьма неплохо. > Кстати, в WebKit яббловцы прикрутили JIT-компиляцию JS с помощью LLVM в качестве > четвертого уровня JIT. ну, любят люди извращения — кто ж им запретить-то может…
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	113. "Основанные на GCC проекты JIT-компилятора и расширения,..."	–1 +/–
	Сообщение от annulen (ok) on 07-Окт-13, 15:17
	>> Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-компиляции. > — алё, Хьюстон, у нас проблемы: воробей! > — спокойно, уже везём ядерную боеголовку! Проще взять готовый фронт-енд для С-подобных языков и готовый бэкэнд для JIT, чем городить велосипеды.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	114. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от arisu (ok) on 07-Окт-13, 15:19
	> Проще взять готовый фронт-енд для С-подобных языков и готовый бэкэнд для JIT, > чем городить велосипеды. — а пользователь? — а нам какое дело? купит процессор поновее и ещё 16GB памяти, это его проблемы!
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	120. "Основанные на GCC проекты JIT-компилятора и расширения,..."	–1 +/–
	Сообщение от annulen (ok) on 07-Окт-13, 18:37
	> «из коробки» оно умеет x86, x86_64 и arm. Мда, и кто-то еще заикается про малое количество архитектур, поддерживаемых LLVM.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	125. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Crazy Alex (ok) on 07-Окт-13, 20:40
	Хм, ну покажи мне хоть как-то живую систему, на которую не портирован GCC. Пусть даже из твоих  полумертвых "каноничных" юниксов.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	126. "Основанные на GCC проекты JIT-компилятора и расширения,..."	–1 +/–
	Сообщение от Аноним (??) on 07-Окт-13, 21:08
	Не выложит, это принципиально. Будет тот же графоманский поток околокомпьютеорных мыслей. Очень правдоподобный для не слишком дотошных, но не практике принципе не проверяемый. Вся суть аризу. "я ощущаю что этот концептуальный подход нелогичен, скучен и приличный человек не будет пользоваться". Спроси про делали и конкретные строки кода или патч - получишь в ответ еще более пространный графоманский водевиль с оскорблениями. Гланвое - ни строки кода.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	127. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Vkni (ok) on 07-Окт-13, 21:13
	> да да.. это как писать сайты имеет смысл под IE, так как > вероятность его наличия близка к 1.. Это только если рассматриваем десктоп. На планшетах и телефонах вероятность наличия IE нулевая. Поэтому писать сайты имеет смысл под Chrome, правда не забывая про IE и FF. > А всякие линуксоиды с их 1% рынка - не интересны не капли.. ведь верно ? Для кого? Для общеупотребительного десктопного софта Linux неинтересен. Для серверов (в том числе и серверов приложений) - вполне. Для планшетов/смартфонов очень интересен. > хотя если для тебя система ограничивается только Linux - то да вероятность > gcc близка к 1.. А если посмотреть чуть чуть шире - > то окажется что это далеко не так. Вопрос - по каким критериям отфильтровываем. См. выше.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	128. "Основанные на GCC проекты JIT-компилятора и расширения,..."	–1 +/–
	Сообщение от Vkni (ok) on 07-Окт-13, 21:19
	> p.s. собственно, после раздумий я не уверен, ошибка ли это компилятора, или > идиотизм стандарта с очередной «неопределённой последовательностью». но принцип > least surprise явно поломан, это раз. и два — если поведение > неопределено, то компилятор должен плюнуть предупреждением. В том виде, что ты написал, это очень похоже на неопределённое поведение. Причём тут даже C++-ом не пахнет, чистый C. И, мне кажется, что именно в таких местах мы и получаем пользу от clang'а.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	129. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от arisu (ok) on 07-Окт-13, 21:31
	> Причём тут даже C++-ом не пахнет, чистый C. я про си и говорил. > И, мне кажется, что именно в таких местах мы и получаем пользу > от clang'а. нулевую. польза — это если бы меня преупреждением обругали. а так — молча делают фигню. почему фигню? потому что принцип «наименьшего сюрприза» диктует ровно обратное тому, что делает кланг. я в упор не помню, что там в стандарте по этому поводу написано (там вообще фигни столько написано, что и у коня голова лопнет), но в приличных домах о явно неприличном поведении принято предупреждать. молчат же оба — и кланг, и гцц. впрочем, я сильно подозреваю, что это действительно неопределённое поведение, просто у компиляторов не хватило сил его заметить. и, в общем-то, зря я на кланг накинулся — на то оно и неопределённое.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	130. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Vkni (ok) on 07-Окт-13, 21:37
	> нулевую. польза — это если бы меня преупреждением обругали. Стат. анализатор у clang'а говно, хотя попробуй, прогони его, авось ругнётся. А для предупреждения эта штука слишком сложна - нужно проанализировать код внутри функции и убедиться, что таки да - меняет поле. > я в упор не помню, что там в стандарте по этому поводу написано (там вообще фигни столько написано, что и у коня голова лопнет) Язык C староват очень.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	131. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от Vkni (ok) on 07-Окт-13, 21:38
	> Не выложит, это принципиально. Будет тот же графоманский поток околокомпьютеорных мыслей. Милый Аноним, вы тоже не понимаете, что заниматься социальными игрищами, надев маску, нельзя?
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	132. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от arisu (ok) on 07-Окт-13, 21:56
	>> нулевую. польза — это если бы меня преупреждением обругали. > Стат. анализатор у clang'а говно, хотя попробуй, прогони его, авось ругнётся. его, вроде, отдельно собирать надо. потом попробую как-нибудь, git всё помнит, если что. > для предупреждения эта штука слишком сложна — нужно проанализировать код внутри > функции и убедиться, что таки да — меняет поле. ну, там сразу перед return'ом ++ стоит, в принципе, ничего заковыристого. обычный data flow analysis, его и так делают. >> я в упор не помню, что там в стандарте по этому поводу написано (там вообще фигни столько написано, что и у коня голова лопнет) > Язык C староват очень. дык вон недавно очередную ревизию стандарта приняли. фигни насовали, полезного — ноль. ну почему, например, не стандартизировать 2's-complement integer arithmetic? почему integer overflow не прописать? да куча софта пользуется тем, что это стандарт де-факто (хоть хэш-функции взять — куча на этом подвязана). почему не добавить конструкцию для проверки флажка переполнения, который есть у подавляющего большинства процессоров? это ведь офигенно упростило бы те же проверки на переполнение, которые можно было бы делать постфактум. вот зачем в очередной раз пересматривать стандарт, чтобы бережно не добавлять туда ничего более-менее полезного irl? какого чёрта было плевать на уже введённый в ISO C90 __inline__ и сделать идиотское _Noreturn вместо __noreturn__? да ну их в анус, академиков сферических. я для себя давно решил, что стандарт — это gnu99, со всеми его вкусными расширениями.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	133. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Vkni (ok) on 07-Окт-13, 21:57
	Программа: 8><----------------------------------------------><8 typedef struct SSS {     int a, b; } SS; SS * f( SS* ss) {     ss->a = 2;     return ss; } int main( int argv, char ** argc) {    SS ss;    ss.a = 1;    ss.b = 3;    f( &ss)->b = ss.a;    return ss.b; } 8><----------------------------------------------><8 Компиляция: [vkni@t60 Arisu.clang]$ gcc test.c -o gcc [vkni@t60 Arisu.clang]$ clang test.c -o clang Как запускать: [vkni@t60 Arisu.clang]$ ./gcc ; echo $? 2 [vkni@t60 Arisu.clang]$ ./clang ; echo $? 1 Версия gcc: x86_64-alt-linux-gcc (GCC) 4.7.2 20121109 (ALT Linux 4.7.2-alt7) Версия clang: clang version 3.3 (tags/RELEASE_33/final) Анализатор clang'а ошибок не выявил: scan-build: No bugs found.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	134. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Vkni (ok) on 07-Окт-13, 21:58
	> Выкладывай отпрепроцессенный файл и опции компиляции, я проверю. https://www.opennet.ru/openforum/vsluhforumID3/91996.html#133
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	135. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Vkni (ok) on 07-Окт-13, 22:00
	> его, вроде, отдельно собирать надо. потом попробую как-нибудь, git всё помнит, если > что. Уже не надо - https://www.opennet.ru/openforum/vsluhforumID3/91996.html#133
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	136. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от arisu (ok) on 07-Окт-13, 22:00
	благодарю. могу от себя добавить, что gcc 4.8.1 на x86 тоже никаких ворнингов не даёт. я, кстати, с -O2 собирал.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	137. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от arisu (ok) on 07-Окт-13, 22:03
	ты мне гешефт поломал, кстати: я-то надеялся, что денег дадут за сэмпл.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	138. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Аноним (??) on 10-Окт-13, 11:41
	> это потому, что про JIT-ы ты тоже знаешь только три символа, как и про X11. Да это пофигу - общую суть затеи с шейдерами и CL ядрами я усек и вижу что народ тяготеет к сборке этого в рантайме, когда оно по факту понадобилось. Почти как JIT по общей логике получается. А gcc на такое исходно никогда никто не затачивал вообще - он обычный такой компилятор. > остальную феерию просто вытер, потому что тут опять «обнять и плакать». Да ну, брось. Ты всякой всякой феерии тоже не меньше генеришь. А насчет иксов и прочая - я буду пользоваться той графической системой которая будет для меня работать лучше. И это явно не про иксы. Насчет того кто в в чем разбирается: реально разбирается в иксах полтора землекопа на всю планету. Остальные приходят в ужас от увиденного и действительно не разбираются в иксах. Ну или по крайней мере в их коде, являюищмся ужасным месивом костылей и подпорок. Лично мне намного интереснее будет посмотреть что такие как ты разбирающиеся будут делать когда парочка грандов типа Кейта Пакарда окончаетльно задолбаются с этим месивом. У тебя и vkni появится чудный шанс показать всему миру как ты там разбираешься.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	139. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Аноним (??) on 10-Окт-13, 11:49
	> jit-компилятором? однозначно не надо, jit-ы не для этого совсем придуманы. Оно достаточно близко по смыслу имхо - код для GPU генерится на лету, по ходу выполнения программы. Обычный компилер на такое дергать - полное извращение. > спокойно используют старую версию функции. а потом libjit заменит её на > новую. при этом позаботившись о том, чтобы ничего не упало и > не сглючило, если какой-то другой поток в это время всё ещё > находится в старом варианте. Хорошо придумано, не отнять. > «из коробки» оно умеет x86, x86_64 и arm. то есть, подавляющее большинство устройств, А как насчет MIPS и PPC?
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	140. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от Аноним (??) on 10-Окт-13, 11:52
	> В LLVM классных плюшек с каждым релизом только прибавляется. Особенно "классно" с LLVM сношались амдшники, которые добрых 2 года пытались убедить этот крап сгененрить просто валидный код для их GPU. Про оптимизацию кода речь вообще не шла - для этого отдельный довесок присобачили. Который к LLVM вообще никак не относится. > И догнать их будет не легко. А поддерживая старый(и зачастую > плохо поддерживаемый код на C) - просто не реально. Я думаю мсье стоило бы почитать что думают практикующие разработчики о "простоте" работы с clang/llvm. Например, мнение от Vadim Girlin, того который оптимизатор шейдеров написал. Ему проще с нуля оказалось написать это чем с шланговской инфраструктурой бодаться.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	141. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Аноним (??) on 10-Окт-13, 11:55
	> вот, кстати, только что в списке рассылки Lua пришло: Справедливости ради - почитай логи коммитов к амдшному окрытому драйверу :). GCC там тоже  досталось на орехи, пришлось баг воркэраундить :)
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	142. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Аноним (??) on 10-Окт-13, 11:57
	> llvm же вполне хорош — для своих применений. А с этим никто и не спорит. Просто объем маркетингового буллшита текущего из некоторых мозгов - утомил.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	143. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Аноним (??) on 10-Окт-13, 12:00
	> На планшетах и телефонах вероятность наличия IE нулевая. А как же виндовс фон? Хотя я согласен - лучше считать его за ноль :) > Поэтому писать сайты имеет смысл под Chrome, А я думал - по стандартам. А вот кто хреново поддерживает стандарты (да, я смотрю на вас, неуважаемые индусы из IE team) - сам себе злобный буратино. > Для кого? Для общеупотребительного десктопного софта Linux неинтересен. А valve в курсе этой фигни? :)
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	144. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от Аноним (??) on 10-Окт-13, 12:01
	> Тем временем парни из IBM уже запилили LLVM и Clang для Power и System Z. Осталось всего ничего: спустить фанатизм в унитаз и честно сообщить нам сколько лет gcc так уже умеет.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	145. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от arisu (ok) on 10-Окт-13, 12:04
	так я и на gcc-шные баги наступал. как-нибудь под настроение — если вспомню — и его попинаю. но кланг пинать забавней.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	146. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Аноним (??) on 10-Окт-13, 12:05
	> оно до сих пор в оптимизации inline-функций косячит, Жесть как она есть...
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	147. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от Аноним (??) on 10-Окт-13, 12:08
	> это вы о большинстве линуксоидных программистов? Это о общей логике развития FBSD. Эталонный пример того как не надо рулить проектом - выбрасывать сие начали даже старые зубры типа ях и апачей, у которых оно по историческим причинам было. И как вы понимаете, если что-то выбрасывают - то в основном потому что много мороки с неочевидным результатом. > которые слов c-std .., POSIX, SUS боятся как огня ?:) Все это имеет довольно косвенное отношение к вменяемости управления проектом.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	148. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от arisu (ok) on 10-Окт-13, 12:11
	>> это потому, что про JIT-ы ты тоже знаешь только три символа, как и про X11. > Да это пофигу я заметил. > общую суть затеи с шейдерами и CL ядрами я усек только вот беда: это не JIT, это кросс-компиляция. «не в лотерею, а в преферанс. не выиграл, а проиграл. не квартиру, а машину. а так всё верно, да.» > Да ну, брось. Ты всякой всякой феерии тоже не меньше генеришь. все ошибаются. я тоже ошибаюсь, конечно. но в темы, где я совсем ничего не понимаю, я стараюсь вообще не лезть. > делать когда парочка грандов типа Кейта Пакарда вот его вообще не надо было туда пускать. «гранд», блин. забирайте это к себе куда угодно и не возвращайте никогда. > У тебя и vkni появится чудный шанс показать всему миру как ты там разбираешься. (пожимает плечами) возможно, придётся. правда, лично я «всему миру» ничего доказывать и показывать не собираюсь, я если буду пилить — то совсем для других целей. потому как форк для распальцовки и сейчас сделать никто не мешает.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	149. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Аноним (??) on 10-Окт-13, 12:13
	> И пофиг, гнутые это расширения, или мелкософтовские. GCC доступен под туеву хучу архитектур и желающие могут впилить туда свою новую архитектуру, если им это надо. MSVS этим похвастаться не может, что и является основной предъявой. Да, gcc может мне код и для AVR'ки мелкотравчатой сгенерить. Будучи запущен в линухе, как 64-битный ELF-бинарник. MSVS так невозможно изогнуть в принципе, по поводу чего и предъявы, собственно.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	150. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от arisu (ok) on 10-Окт-13, 12:15
	>> jit-компилятором? однозначно не надо, jit-ы не для этого совсем придуманы. > Оно достаточно близко по смыслу имхо — код для GPU генерится на > лету, по ходу выполнения программы. Обычный компилер на такое дергать — > полное извращение. оно совершенно далеко и по смыслу, и по целям, и по требованиям. и вот ты как раз предлагаешь «дёргать обычный компилер», только через задницу. > А как насчет MIPS и PPC? они ждут своих героев. изначально libjit делаласть для DotGNU, чего там на мипсах ловить? но оно и ARM не умело тоже. потом научили. а MIPS и PPC пока никому не понадобились, видимо. научи — будет круто. иначе, как понимаешь — интерпретатор.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	151. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от arisu (ok) on 10-Окт-13, 12:17
	>> оно до сих пор в оптимизации inline-функций косячит, > Жесть как она есть… справедливости ради: это скорее разница в поведении на сборке программы с неопределённым поведением, чем реальный косяк кланга. тем не менее, «принцип наименьшего удивления» кланг не соблюдает. по моему мнению — стоило бы.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	152. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от arisu (ok) on 10-Окт-13, 12:20
	> А с этим никто и не спорит. Просто объем маркетингового буллшита текущего > из некоторых мозгов — утомил. казалось бы: при чём тут огрызок…
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема