JIT --- стандарт?

Они могут быть уверены, что без JIT их интерпретатор останется (почти) никому не нужным. Тормозных интерпретаторов сейчас много.

Я вот думал, а какова вероятность успеха, если они сделают тормозной, но маленький интерпретатор, мол, позже кто-то допилит?

Как у рубей наверное.

Возможно, но руби вышла, когда компиляция на лету не была такой популярной. То есть если кто-то выбирал ЯП, то отсутствие JIT не было бы минусом.

Хош чтобы не было жита - заяви в требованиях реальное время. Типа, пока жит будет сопли жевать, поциент умрёт

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

чтобы у ЯП был низкий порог вхождения.

там, где нехватает скорости, подкрутим кэширование. не вопрос.

главное помнить, что язык программирования делают для людей, а не для компьютера.

Кодеры на C и Assembler смотрят на тебя с непониманием

чтобы у ЯП был низкий порог вхождения.

Это относительно.

там, где нехватает скорости, подкрутим кэширование. не вопрос.

Покажите, где в питоне подкрутить кэширование, чтобы имердж работал быстрее.

главное помнить, что язык программирования делают для людей, а не для компьютера.

Для обоих.

чтобы имердж работал быстрее

эээ... ну вот смотри, какие действия тебе не критичны, пишешь в файл, а потом читаешь. вот.

эээ… ну вот смотри, какие действия тебе не критичны, пишешь в файл, а потом читаешь. вот.

Сколько телодвижений. ;)

А ведь JIT действительно бы помог.

Может. Но скорее нет, чем да. Маленьких интерпретаторов много, на этом одном далеко не уедешь.

Пожалуй, да. Но всё же, если бы маленький интерпретатор был стандартной реализацией языка, был бы ЯП для скриптов и каких-то девайсов.

существуют сторонние проекты (РуРу)

Оно где-то используется в дикой природе?

Они их имеют, потому что программы на них стали долгоживущими. Для bash например jit не имеет смысла, потому что:
1. Средний скрипт будет дольше компилироваться, чем исполняться;
2. Скрипт будет работать недостаточно долго, чтобы jit мог собрать информацию о горячих точках, которым нужна оптимизация компиляцией.

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

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

В перспективе, думаю, да.

Будут ли товарищи из университета делать JIT — это в первую очередь зависит от их целей и программы исследований.

Но вообще сейчас есть LLVM, там JIT уже готовый — это больше не черная магия, университетские товарищи или их промышленные коллеги вполне могут его к интерпретатору прикрутить, если о производительности задумаются.

Кодеры на C и Assembler смотрят на тебя с непониманием

Языки, которые были придуманы чтобы не писать в машинных кодах.

где-то в университете сейчас проектируют интерпретируемый язык программирования

Но зачем?

Может быть много причин: от банального «всё остальное — днище» и до NIH.

Я к тому, что надобность в jit зависит от предназначения языка.

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

А, безусловно, я взял стандартную ситуацию с ЯП общего назначения.

Можно делать jit, можно не делать — для внешнего наблюдателя разницы не будет никакой

Но ведь если проект и будет начат из-за NIH, не факт, что это не привлечёт сторонних разработчиков.

Зачем сторонним разработчикам чужой NIH?

Кто-то заинтересовался странным проектом.

Вот возьмите какой-то новый джаваскрипт-фреймворк, вот вам и пример.

Ок, давай перефразирую. Если новый язык не решает каких-то серьезных и реальных проблем, присущих уже существующим и популярным языкам, то он заведомо никому не нужен и обречен. Если хочешь, можешь подложить в могилку к этому мертвецу jit. А можешь не подкладывать. Ничего не изменится. Мертвецам, в сущности, всё безразлично.

Если он какие-то проблемы всё-таки решает, то ... вероятно, ему присуща какая-то определенная ниша. И надобность в jit будет определяться спецификой ниши и спецификой самого языка.

Общего рецепта - не существует.

Если он какие-то проблемы всё-таки решает, то … вероятно, ему присуща какая-то определенная ниша. И надобность в jit будет определяться спецификой ниши и спецификой самого языка.

Общего рецепта - не существует.

Поэтому я и уточнил, что язык общего назначения.

Не обязательно, есть достаточно задач, для которых не сильно важна производительность.

Например, bash как работал медленно, так и продолжает, и ничего страшного с ним не происходит - у него по-прежнему полно пользователей. Вряд ли существенная доля его пользователей перейдёт на другой шелл, даже если он будет в тысячу раз быстрее.

Да нифига, paludis на сишечке такой же тормозной был

Хм, не смотрел его, интересно. Всё же думаю, что переход на руру был бы хорошим решением.

А чего же так, видимо, он упирается во что-то другое.

bash как работал медленно, так и продолжает, и ничего страшного с ним не происходит

Вопрос был про новые интерпретаторы. Старые уже позанимали свои ниши, и прочно сидят за счёт накопленного легаси-кода.

Вряд ли существенная доля его пользователей перейдёт на другой шелл, даже если он будет в тысячу раз быстрее.

Многие утилиты начинались с шелл-скриптов и перешли на другие языки именно из-за скорости. Если вдруг появится шелл совместимый с bash, почти не требующий править накопленные скрипты, не более требовательный к памяти и процессору, но на 1-2 порядка быстрее, все быстро пересядут на него. Но появится вряд ли.

Многие утилиты начинались с шелл-скриптов и перешли на другие языки именно из-за скорости.

Нет.

На другие языки с шелла переписывают в первую очередь вот из-за этого невменяемого бардака: https://mywiki.wooledge.org/BashPitfalls

Написать содержательный скрипт на шелле и при этом ни в чём не обосраться - это что-то из разряда ненаучной фантастики.

И shellcheck не спасёт.

Поэтому я и уточнил, что язык общего назначения.

Язык общего назначения уже есть. И не один. Они есть всех размеров, цветов и фасонов.

С таким подходом к разработке языка, какой ты озвучил, вопрос о jit не релевантен.

Язык общего назначения уже есть. И не один. Они есть всех размеров, цветов и фасонов.

Так у нас и антибиотиков вон сколько есть, новые перестать создавать?

Всё же думаю, что переход на руру был бы хорошим решением.

Когда я юзал генту, я видел гайд по руру, в котором было сказано, что значительного прироста производительности не будет, а вот жор памяти будет) В связи с чем и был мой вопрос.

На своём сайте они говорят, что:

memory-hungry Python programs (several hundreds of MBs or more) might end up taking less space than they do in CPython.

Но появится вряд ли.

Как мне кажется, это так, потому что вряд ли найдётся кто-то, кто захочет потратить много своих сил, чтобы разогнать bash. Он и так достаточно хорош для текущих задач.

Вопрос был про новые интерпретаторы.

PowerShell, AppleScript. AutoHotkey появился не слишком давно. Всякие внутренние языки в игрушках (QuakeC). Скрипты в криптовалютах (но тут я не уверен, можно ли назвать их языками общего назначения). В макроязыке VBA, что используется в Microsoft Office и AutoLisp из AutoCAD вроде бы нет JIT.

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

Нет, конечно, какой JIT новорождённому языку. Взлетит дай бог каждый тысячный язык, потом на AOT посидит — не облезет, CPython не даст соврать.

Такое ощущение, что все участники треда пребывают в состоянии ложной дихотомии «либо JIT, либо медленно».

А у баша есть джыт?

Вы таки шото имеете против джытов?

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

JIT-компиляция была уже в 80-х годах как минимум для APL, Smalltalk и лиспа. Сам лисп к этому времени уже стал поддерживать AOT компиляцию с четким разделением на время разработки и время выполнения. И, тем не менее, уже в девяностые откуда-то прорвалась плотина со школьниками-студентами, которые строили свою собственную велосипедную технологию с чистого листа, будто 30 лет разрабокти софта до них не существовало. Это я сейчас про PHP, Python, Ruby.

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

Дальше немного технических подробностей по JIT. На самом деле, если на этапе парсинга текстового исходника поменять строковые ключи на хэши, то ты получишь довольно простые и быстрые запросы к хэш-таблицам по числовым ключам, которые по производительности мало отличаются от чтения какой-нибудь сишного массива по числовому смещению, разве что используют чуть больше оперативной памяти. Проблема производительности начинается из-за того, что по целевому адресу в хэш-таблице лежит не значение, а ссылка на контейнер со значением, и вместо одного чтения ты получаешь минимум два. Причем, эта же проблема актуальна и для Java — сейчас уже никто не запускает жаву без JIT, но на самом деле жава без JIT почти такая же медленная, как питон или PHP с предварительной оптимизацией на этапа парсинга. И именно потому, что у современных процессоров минимальный блок обрабатываемой памяти в основном составляет 64 байта, и независимо от того, читаешь ли ты 1 байт или 32 байта — процессор будет работать с блоком 64 байт.

Второй важный фактор, который уронил уровень производительности жавы без JIT до уровня PHP/Python — это вызовы методов-однострочников. Вызов функции на каком-нибудь x86 стоит порядка 15 циклов. Это без самого тела. Потому не важно, насколько эффективный и оптимизирующий AOT компилятор у тебя будет — ничего не получится, пока ему приходится делать вызовы однострочников. Для того, чтобы эффективно скомпилировать AOT хотя бы какое-нибудь «a+b», нужно заранее, на этапе компиляции, знать типы a и b, чтобы взять нужные однострочники и заинлайнить их работу без вызовов функций. Язык, который позволяет выводить типы, например, RPython, имеет огромное преимущество над куском дерьма, вроде CPython, в котором нет никакой возможности гарантировать тип значения до непосредственного выполнения строки кода.

Оно где-то используется в дикой природе?

Используются, но совместимость не идеальная (потому что у питона спецификация конкретной реализацией), и практическая польза достигается на довольно ограниченном числе задач, в основном это какие-то примитивные операции на чистом питоне, вроде числодробилки в цикле без вызова сторонних сишных библиотек, потому что сишные функции нельзя оптимизировать. И самое печальное то, что таки питон ценен именно благодаря готовым либам на сишке — язык сам по себе бесполезен. Конечно, если вообще кто-то сможет найти там какой-то язык, поскольку семантики у языка почти нет, а синтаксис постоянно расширяется.

Но вообще сейчас есть LLVM, там JIT уже готовый — это больше не черная магия, университетские товарищи или их промышленные коллеги вполне могут его к интерпретатору прикрутить, если о производительности задумаются

У LLVM нет никакого JIT — там есть On-Request Compiler, который может генерировать платформоспецифичный код во время выполнения для твоего JIT-оптимизатора, то есть, LLVM выступает в качестве бэкэнда JIT-компилятора. «Фронтэнд», который скармливать LLVM оптимизированные констуркции, по прежнему нужно писать самому под каждый конкретный язык.

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

JIT-компиляция была уже в 80-х годах как минимум для APL, Smalltalk и лиспа

Smalltalk вообще был революционным.

И, тем не менее, уже в девяностые откуда-то прорвалась плотина со школьниками-студентами, которые строили свою собственную велосипедную технологию с чистого листа, будто 30 лет разрабокти софта до них не существовало. Это я сейчас про PHP, Python, Ruby.

Дело в том, что «школьников-студентов» большинство, если же один из них создаёт язык, он учитывает требования этой категории людей. Раньше языки создавали либо профессора в университетах (и выходили академические ЯП), либо матёрые программисты, которые проектировали каждую деталь языка, но это ведь не подходит большинству людей.

Позволю себе несколько отойти от темы. РНР ведь и не проектировался как ЯП, это был простой набор скриптов сиджиай. ЕНИП, Smalltalk, имея JIT, был медленее джавы с самого начала.

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

Это норма для скриптоты. В пыхе то же самое.

PowerShell

Создан около 18 лет назад как альтернатива свободным шеллам, вобравшая всё хорошее из VBS, которым никто не хотел пользоваться из-за сложившейся репутации.

AutoHotkey

Создан около 18 лет назад для узкой задачи автоматизации виндового GUI.

QuakeC

25 лет. За пределами Quake не применяется.

VBA

28 лет. Владельцы пытаются его похоронить уже 13 лет. В своей нише замены нет.

AutoLisp

35 лет.

Насколько я знаю, Перл без JIT в 100 раз медленнее Си, остальные ещё медленнее. Есть ли интерпретаторы быстрее Перла?

CPython тоже без JIT, но с AOT.

AOT

Это считается интерпретатором?

Ну интерпретирует же =D Набери «python» и убедись.