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

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

"Пример использования средств JIT-компиляции, появившихся в G..."	+/–
Сообщение от opennews (ok) on 08-Апр-15, 20:09
Разработчики из компании Red Hat опубликовали интересную заметку (http://developerblog.redhat.com/2015/04/07/jit-compilation-u.../) с примером использования библиотеки libgccjit (https://gcc.gnu.org/wiki/JIT), которая входит в состав набора компиляторов GCC 5 (https://gcc.gnu.org/gcc-5/changes.html), релиз которого ожидается через несколько недель. В GCC 5 генератор кода может быть собран в виде разделяемой библиотеки, встроен в другие процессы и использован для  упреждающей AOT-компиляции (Ahead-of-time) или  JIT-компиляции байткода в машинный код. В заметке показано как построить компилятор для гипотетического языка программирования, используя Python-биндинг (https://pypi.python.org/pypi/gccjit) к libgccjit для JIT-компиляции кода в Python-скрипте. URL: http://developerblog.redhat.com/2015/04/07/jit-compilation-u.../ Новость: http://www.opennet.dev/opennews/art.shtml?num=41999
Ответить | Правка | Cообщить модератору

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

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

1. "Пример использования средств JIT-компиляции, появившихся в G..."	+3 +/–
Сообщение от nc (ok) on 08-Апр-15, 20:09
Компиляторы из промежуточного представления в бинарное имеют смысл при инсталляции кроссплатформенных программ из единого источника на разные аппаратные платформы. Это то что гугл сделал в виде art. А JIT как компиляция каждый раз при запуске программы - а нафиг это нужно?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Пример использования средств JIT-компиляции, появившихся в G..."	–5 +/–
	Сообщение от A.Stahl (ok) on 08-Апр-15, 20:21
	Писать скрипты в сишном коде не на lua или, избавь Ктулху, на JavaScript, а на Си. Звучит офигительно.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Пример использования средств JIT-компиляции, появившихся в G..."	+5 +/–
	Сообщение от Аноним (??) on 08-Апр-15, 20:25
	Что-то я не вижу ничего хорошего в скриптах на Си. Если же вы думаете, что это поднимет средний уровень скриптов, то я скорее предположу, что это понизит средний уровень программистов на Си.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от A.Stahl (ok) on 08-Апр-15, 20:28
	Есть программа на Си. Нужно в ней что-то скриптовое. Разумеется лучше чтобы этот скрипт будет написан на Си, чем сишник будет ещё разбираться с lua или ещё чем похуже.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	6. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от Сергей (??) on 08-Апр-15, 20:44
	Какой кусок кода в гипотетической, но уже написанной C-шной программе "разумеется лучше" не компилировать для конечного использования?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	10. "Пример использования средств JIT-компиляции, появившихся в G..."	–1 +/–
	Сообщение от A.Stahl (ok) on 08-Апр-15, 20:49
	Скриптовый. Т.е. часто изменяемый. Возможно даже пользователем.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	14. "Пример использования средств JIT-компиляции, появившихся в G..."	+2 +/–
	Сообщение от Сергей (??) on 08-Апр-15, 20:53
	Пользоветель скорее умрет, но попросит сделать поддержку LUA вместо С.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	15. "Пример использования средств JIT-компиляции, появившихся в G..."	–1 +/–
	Сообщение от Сергей (??) on 08-Апр-15, 20:54
	"Частоизменяемый" не проблема компилировать при разработке.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	19. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от Вулх on 08-Апр-15, 21:09
	В том то и дело, что изменяемый при эксплуатации, а не при разработке.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	34. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от Сергей (??) on 09-Апр-15, 03:21
	Смотри пост 7.14
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	7. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от Сергей (??) on 08-Апр-15, 20:46
	Чем лучше писать скрипты на C по сравнению с LUA?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	11. "Пример использования средств JIT-компиляции, появившихся в G..."	–1 +/–
	Сообщение от A.Stahl (ok) on 08-Апр-15, 20:50
	> Чем лучше писать скрипты на C по сравнению с LUA? Тем, что зная Си ты уже автоматичемски знаешь Си. Круто, да? А вот знание Си никак не обеспечивает знание Lua. :)
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	17. "Пример использования средств JIT-компиляции, появившихся в G..."	+6 +/–
	Сообщение от Сергей (??) on 08-Апр-15, 20:58
	Знание C/C++/Tcl/BASH мне тут же обеспечило знание LUA. Попробуй под пытками заставить человека, знающего только LUA,Tcl и BASH хоть что-то написать на C/C++ -- человек погибнет. ;-)
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	37. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от Vkni (ok) on 09-Апр-15, 06:09
	> Тем, что зная Си ты уже автоматичемски знаешь Си. Круто, да? > А вот знание Си никак не обеспечивает знание Lua. > :) Все знают Бейсик, но это же не повод писать на нём абсолютно всё.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	42. "Пример использования средств JIT-компиляции, появившихся в G..."	+1 +/–
	Сообщение от cmp (ok) on 09-Апр-15, 08:45
	да ну
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	9. "Пример использования средств JIT-компиляции, появившихся в G..."	+1 +/–
	Сообщение от Аноним (??) on 08-Апр-15, 20:48
	Обычно что-то скриптовое в программе нужно для расширения функциональности пользователем, а не программистом.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	43. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от cmp (ok) on 09-Апр-15, 08:56
	О чем речь, если оно поддерживает си, то и луа автоматом, кому надо луа пусть его юзает, кому надо си пусть юзает его, программировать плагины, думаю, будет гораздо удобнее. Если оно будет динамически обновлять код по ходу выполнения, так это сказка.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	12. "Пример использования средств JIT-компиляции, появившихся в G..."	+2 +/–
	Сообщение от Сергей (??) on 08-Апр-15, 20:52
	Я всего один раз написал на LUA, но с полпинка небольшой скрипт без предварительной подготовки вообще(C не в счёт). Если дать LUA-программисту, не видевшему C, аналогичную, но обратную задачу: написать то же самое не C -- он помрёт тут же.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	8. "Пример использования средств JIT-компиляции, появившихся в G..."	+1 +/–
	Сообщение от Аноним (??) on 08-Апр-15, 20:47
	Lua божественнен. Один из самых шустрых скриптовых языков, очень малые затраты на выполнение и встаривание.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	13. "Пример использования средств JIT-компиляции, появившихся в G..."	–1 +/–
	Сообщение от A.Stahl (ok) on 08-Апр-15, 20:52
	Ну никто и не утверждает обратного. Но сишникам приятней будет использовать Си уже потому, что он Си. На родном языке всегда проще.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	16. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от Аноним (??) on 08-Апр-15, 20:56
	Проще что? На самолёте проще чем на троллейбусе.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	18. "Пример использования средств JIT-компиляции, появившихся в G..."	–1 +/–
	Сообщение от A.Stahl (ok) on 08-Апр-15, 21:04
	>Проще что? всё
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	45. "Пример использования средств JIT-компиляции, появившихся..."	+1 +/–
	Сообщение от arisu (ok) on 09-Апр-15, 17:57
	>>Проще что? > всё хэш‐таблицы, например. куда уж несчастным скриптовикам до няшности и удобства использования хэш‐таблиц в си…
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	26. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от Crazy Alex (ok) on 09-Апр-15, 00:03
	Для скриптовых нужд у C уж больно слабо в плане синтаксиса и высокоуровневых конструкций. Я сишник, но писать на сях скрипты мне в голову бы не пришло. Вот на D и программа и скрипт - без проблем. На плюсах - тоже можно хотя бы сделать по-человечески, спрятав всё управление временем жизни, ресурсами, памятью. Хотя, конечно, скорость компиляции... Но на C? С явным управлением ресурсами (или адскими костылями), со здоровенными префиксами имён функций вместо красивого объектного синтаксиса, без приличных средств обработки ошибок... да ну его на фиг. Вообще - для скриптов есть питон. Это та область, где он на месте - нагрузки никакой (вся работа делается в компилируемом коде, который из питона только зовётся), читается в небольших количествах легко, интуитивно довольно понятен.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	28. "Пример использования средств JIT-компиляции, появившихся в G..."	–3 +/–
	Сообщение от Led (ok) on 09-Апр-15, 00:05
	> Для скриптовых нужд у C уж больно слабо в плане синтаксиса и > высокоуровневых конструкций. Начал "за здравие"... > Вообще - для скриптов есть питон. ... а закончил "за упокой".
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	33. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от Crazy Alex (ok) on 09-Апр-15, 02:34
	И в чём проблема? Для скриптов нужно что-то, где, как минимум, можно автоматом управлять памятью и иметь нормальную итерацию. Ну и всякий удобный синтаксический сахар вроде питоновских list comprehensions. си не годится, а питон - вполне, для того и создан.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	30. "Пример использования средств JIT-компиляции, появившихся в G..."	–1 +/–
	Сообщение от Анончег on 09-Апр-15, 01:29
	>... На плюсах - тоже можно хотя бы сделать по-человечески, спрятав всё управление временем жизни, ресурсами, памятью. Хотя, конечно, скорость компиляции ... Precompiled Headers ?! Нет, не слышал. https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	32. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от Crazy Alex (ok) on 09-Апр-15, 02:29
	Их хватает, чтобы компиляция не занимала вечность, но не для того, чтобы компилировать плюсы на лету.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	38. "Пример использования средств JIT-компиляции, появившихся в G..."	–1 +/–
	Сообщение от Vkni (ok) on 09-Апр-15, 06:11
	> На плюсах - тоже можно хотя бы сделать по-человечески Нельзя.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	35. "Пример использования средств JIT-компиляции, появившихся в G..."	+3 +/–
	Сообщение от Сергей (??) on 09-Апр-15, 03:25
	> На родном языке всегда проще. Запатентуй компилятор мата -- обогатишься. ;-)
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	44. "Пример использования средств JIT-компиляции, появившихся в G..."	–1 +/–
	Сообщение от Аноним (??) on 09-Апр-15, 11:34
	Вообще-то, libgccjit - это всего лишь backend, т.е. генератор машинного кода. А вот фронтенд для C вам придется написать самим. Эта задачка посложнее всей libgccjit будет. Так что сабж подходит для чего-то простого, что при этом кровь из носу надо скомпилировать налету. Даже не знаю, что это могло бы быть. А для "скриптов на C" лучше смотреть в сторону clang.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	5. "Пример использования средств JIT-компиляции, появившихся в G..."	+4 +/–
	Сообщение от Tav (ok) on 08-Апр-15, 20:30
	Для разного нужно: - динамическая оптимизация программы с учетом текущего профиля выполнения (JVM); - модификация программы во время выполнения (Лисп, Смолток и др.); - предметно-ориентированные языки, являющиеся частью интерфейса пользователя.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	23. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от freehck (ok) on 08-Апр-15, 22:18
	> динамическая оптимизация программы с учетом текущего профиля выполнения (JVM); Ну, это скорее её недостаток. Ей ведь надо балансировать между скоростью запуска и скоростью работы, вот и выкручиваются, как могут. > модификация программы во время выполнения (Лисп, Смолток и др.); Вот. Именно для этого JIT и нужен в первую очередь. Но упаси боже, не в том же виде, в каком предлагают его LLVM и JVM. > предметно-ориентированные языки, являющиеся частью интерфейса пользователя. А вот тут я бы попросил объяснить, что имеется в виду.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	24. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от Tav (ok) on 08-Апр-15, 23:00
	> Ну, это скорее её недостаток. Ей ведь надо балансировать между скоростью запуска и скоростью работы, вот и выкручиваются, как могут. На серверах, где программа перезапускается редко и работает долго, это не проблема. > Но упаси боже, не в том же виде, в каком предлагают его LLVM и JVM. В чем суть отличий "того же вида" от не того? > А вот тут я бы попросил объяснить, что имеется в виду. Различные системы, предоставляющие пользователю специализированный язык для решения его задач: Маткады всякие, статистические пакеты типа R или Incanter, шеллы, приложения с поддержкой макрокоманд, мало ли что еще. JIT в них не всегда оправдан, но бывают случаи, когда объем вычислений значителен и JIT окупается.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	31. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от Анончег on 09-Апр-15, 01:33
	> В чем суть отличий "того же вида" от не того? Да, да, поддерживаю, пускай расскажет нам про "Ъ-виды" и "НЕ-Ъ-виды".
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	40. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от freehck (ok) on 09-Апр-15, 07:03
	>> Ну, это скорее её недостаток. Ей ведь надо балансировать между скоростью запуска и скоростью работы, вот и выкручиваются, как могут. > На серверах, где программа перезапускается редко и работает долго, это не проблема. А у программ скомпилированных "до конца", такой проблемы нет. >> Но упаси боже, не в том же виде, в каком предлагают его LLVM и JVM. > В чем суть отличий "того же вида" от не того? Суть в том, что от проектов LLVM и JVM то и дело слышны возгласы, что мол проекты позволяют достигнуть производительности компилируемых языков, и что производительность их за так сильно возросла именно за счёт JIT. Надо понимать, что JIT всё-таки хоть и может привести к повышению производительности, но вообще говоря не для неё создан, ибо "до конца" с компилированные программы по-любому дадут более оптимизированный код. А вот что касается возможности генерации кода на лету - то это действительно очень востребовано. Во-первых любой REPL[1] на этом основан, во-вторых - очень удобно генерировать функцию на лету и возвращать её в качестве результата работы другой функции. "Да и вообще, какой смысл писать программу, которая даже не умеет модифицировать свой код?" [2] >> А вот тут я бы попросил объяснить, что имеется в виду. > Различные системы, предоставляющие пользователю специализированный язык для решения > его задач: Маткады всякие, статистические пакеты типа R или Incanter, шеллы, > приложения с поддержкой макрокоманд, мало ли что еще. JIT в них > не всегда оправдан, но бывают случаи, когда объем вычислений значителен и > JIT окупается. Ну, это всё же частные случаи второго пункта, про модификацию программы во время выполнения. [1] https://ru.wikipedia.org/wiki/REPL [2] http://jim.pp.ru/chtivo/prosa/porgrammerstory.htm
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	46. "Пример использования средств JIT-компиляции, появившихся в G..."	–1 +/–
	Сообщение от Tav (ok) on 10-Апр-15, 18:13
	> Суть в том, что от проектов LLVM и JVM то и дело слышны возгласы... Ну это не технические отличия, а вопрос позиционирования. И на самом деле, производительность можно улучшить за счет JIT. Например, JIT позволяет вызывать напрямую или даже встраивать полиморфные вызовы, если во время выполнения оказывается, что используется только одна реализация (может зависеть от входных данных — оптимизировать статически не получится). А встраивание делает возможными дальнейшие оптимизации. Если что-то меняется, что может нарушить сделанные допущения, оптимизация отменяется. Обзор оптимизаций, которые выполняет HotSpot: https://wikis.oracle.com/display/HotSpotInternals/Performanc... Но возможность динамически менять код — более важное применение, с этим согласен. > Ну, это всё же частные случаи второго пункта, про модификацию программы во время выполнения. Можно считать и так. Выделил отдельно, чтобы обратить внимание на то, что технология может быть непосредственно полезна не только разработчикам, но и конечным пользователям.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	47. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от freehck (ok) on 22-Июн-15, 15:26
	>> Суть в том, что от проектов LLVM и JVM то и дело слышны возгласы... > Ну это не технические отличия, а вопрос позиционирования. > И на самом деле, производительность можно улучшить за счет JIT. Например, JIT > позволяет вызывать напрямую или даже встраивать полиморфные вызовы, если во время > выполнения оказывается, что используется только одна реализация (может зависеть от входных > данных — оптимизировать статически не получится). Да, это может дать прирост производительности. Однако я не очень представляю, как оптимизации, основанные на входных данных могут быть произведены автоматически. Это наверняка потребует строго выдержанного стиля кода, отступление от которого приведёт к невозможности подобных оптимизаций. Если бы Вас не затруднило предоставить примеры, где подобный подход действительно применяется и даёт выигрыш - было бы здорово. К тому же, не стоит забывать, что такой подход подразумевает возрастающие накладные расходы для постоянного анализа входных данных, чтобы отловить случай, когда они перестанут удовлетворять выбранной по умолчанию реализации. Об этом в частности свидетельствует Ваша ссылка[1]. Окупятся ли данные расходы за счёт JIT - тоже нетривиальный вопрос. Итого мы стоим лицом к лицу со многими неочевидными вопросами и сомнительным выигрышем в производительности. Собственно, для меня это и является причиной считать LLVM и JVM - не правильной вещью. [1] https://wikis.oracle.com/display/HotSpotInternals/Performanc... PS: Извиняюсь за столь длительную задержку с ответом -- меня выбила из колеи магистерская диссертация. Если у Вас будет желание, мы могли бы продолжить дискуссию по email.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	21. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от Аноним (??) on 08-Апр-15, 21:43
	> А JIT как компиляция каждый раз при запуске программы - а нафиг это нужно? Как-то так шейдеры в GPU вгружают например. Хотя иногда скомпиленое и кэшируют.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	22. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от КарМер on 08-Апр-15, 22:17
	"Разные аппаратные платформы " - это и разное число ядер, в том числе ...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	29. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от Crazy Alex (ok) on 09-Апр-15, 00:07
	Тогда не JIT,  а просто сборка на клиенте. Но вообще-то разное число ядер в коде спокойно обрабатывается. Пул потоков, очередь заданий,да и всё
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	25. "Пример использования средств JIT-компиляции, появившихся в G..."	–1 +/–
	Сообщение от Qld on 08-Апр-15, 23:38
	JIT-компиляция может учесть все экстенжены текущего процессора, что приведет к заметному бусту высоко нагруженных длительных вычислений.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	27. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
	Сообщение от Crazy Alex (ok) on 09-Апр-15, 00:05
	Так здесь не JIT,  а вполне себе нормальная AOT-компиляция нужна - при первом запуске собрал (или до него - привет Гента), закешировал и пусть лежит.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

20. "Пример использования средств JIT-компиляции, появившихся в G..."	+/–
Сообщение от Аноним (??) on 08-Апр-15, 21:28
>библиотеки libgccjit, которая входит в состав набора компиляторов GCC 5, релиз которого ожидается через несколько недель GCC 5 начинает догонять старые версии LLVM :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	36. "Пример использования средств JIT-компиляции, появившихся в G..."	+4 +/–
	Сообщение от MaMoHT on 09-Апр-15, 05:05
	> GCC 5 начинает догонять старые версии LLVM :) Забавность ситуации заключается в том, что у gcc намного более богатые возможности по расширению - от легкого расширения ast дерева (в llvm это можно сделать только на  интринсиках) до распараллеливания на GPU "из коробки". И открыв функциональность по jit они не догоняют "старые версии llvm" а уходят в далекий-предалекий отрыв. Порог вхождения в gcc выше, и новичку намного легче написать frontend на llvm, но когда узнаешь все возможности gcc, то llvm перестает казаться даже адекватной альтернативой. Однако это не умаляет достоинства llvm, они дали очень хороший "пинок" для развития gcc. Конкуренция это всегда хорошо. И может быть они когда нибудь догонят gcc по возможностям...
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	41. "Пример использования средств JIT-компиляции, появившихся в G..."	+1 +/–
	Сообщение от freehck (ok) on 09-Апр-15, 07:09
	> Однако это не умаляет достоинства llvm, они дали очень хороший "пинок" для > развития gcc. Конкуренция это всегда хорошо. И может быть они когда > нибудь догонят gcc по возможностям... Это вряд ли. Они ведь компилируются только в одну архитектуру, а потом на лету пытаются перекомпилироваться в машинные коды. Трижды ха. Это конечно определённо даёт фору в реализации новых стандартов ЯП, но жутко демпингует их по качеству сгенерированного кода. JIT относительно хорош для многих вещей, но не для оптимизации же. Однако конкуренция - таки да, это хорошо.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

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

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