The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Для Python предложен JIT-компилятор, использующий технику copy-and-patch, opennews (??), 26-Дек-23, (0) [смотреть все]

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


12. "Для Python предложен JIT-компилятор, использующий технику co..."  –1 +/
Сообщение от _kp (ok), 26-Дек-23, 15:17 
JIT - это лишние тормоза, считай полумеры.
Так бы и написали что компиляцию в нативный код не осилили, ибо из за динамической типизации все равно фигня с производительностью.
Ответить | Правка | Наверх | Cообщить модератору

33. "Для Python предложен JIT-компилятор, использующий технику co..."  +4 +/
Сообщение от Bottle (?), 26-Дек-23, 17:04 
JIT потенциально обладает преимуществом перед обычной компиляцией. Вот есть у тебя куча ветвлений switch-case в коде, профилировщик собирает статистику и на основе этого компилирует код так, чтобы первыми проверялись самые частые case'ы.
Это, к слову, также положено в основу PGO.
Ответить | Правка | Наверх | Cообщить модератору

35. "Для Python предложен JIT-компилятор, использующий технику co..."  –2 +/
Сообщение от Аноним (35), 26-Дек-23, 17:16 
Ты с if/else не попутал?

switch/case выстраивает jump table, там похер в каком порядке идут значения

Ответить | Правка | Наверх | Cообщить модератору

46. "Для Python предложен JIT-компилятор, использующий технику co..."  +2 +/
Сообщение от Bottle (?), 26-Дек-23, 18:27 
Семантически switch-case и if-else одинаковы, современные компиляторы их разворачивают в одинаковые инструкции 100%. Это раньше могли быть приколы вида того, что for(;;) и while(true) преобразовались в разные ассемблерных инструкции.
Ответить | Правка | Наверх | Cообщить модератору

52. "Для Python предложен JIT-компилятор, использующий технику co..."  +/
Сообщение от Аноним (52), 26-Дек-23, 19:04 
Вы путаете обычный switch и switch с паттерн матчингом. Для обычного свитча компилятор собирает lookup табличку, в которой jmp на нужную ветку идёт даже без cmp инструкций. А вот паттерн матчинг разворачивается в обычные if со всеми вытекающими
Ответить | Правка | Наверх | Cообщить модератору

82. "Для Python предложен JIT-компилятор, использующий технику co..."  +/
Сообщение от Аноньимъ (ok), 27-Дек-23, 00:47 
Это исключительно зависит от конкретного ЯП.
Что там будет вкомпилировпнно и или выполненно в итоге.
Ифы тоже можно в jmp развернуть.

Bottle выше правильно пишет. Это одно и то же в разной записи.

Ответить | Правка | Наверх | Cообщить модератору

53. "Для Python предложен JIT-компилятор, использующий технику co..."  –1 +/
Сообщение от Аноним (35), 26-Дек-23, 19:10 
Что ты, блин, несёшь? Ты сам то проверял? Ничего там не одинаково.
Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

54. "Для Python предложен JIT-компилятор, использующий технику co..."  +/
Сообщение от Аноним (-), 26-Дек-23, 19:28 
Это если у тебя switch по перечисляемому+упорядочиваемому типу, и если используется непрерывный диапазон значений этого типа. Попробуй создать джамптабличку для:

switch(n) {
   case 1: ...;
   case 2: ...;
   case 3: ...;
   case 5: ...;
   case 8: ...;
   case 13: ...;
   ...
   case fib(n): ...; // это на случай если твоя недопёрла как посчитать остальные константы
   ...
   default: ...;
}

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

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

57. "Для Python предложен JIT-компилятор, использующий технику co..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok), 26-Дек-23, 20:22 
Для первого куска делаешь таблицу с null-дырками, для второго обычное дерево или вообще линейный поиск если case-ов мало. А как оно будет на самом деле зависит от компилятора, так-то некоторые и эквивалентный каскад из if-ов умеют в таблицу упаковывать.
Ответить | Правка | Наверх | Cообщить модератору

61. "Для Python предложен JIT-компилятор, использующий технику co..."  +/
Сообщение от Аноним (-), 26-Дек-23, 20:55 
Умница дочка!

Теперь ты можешь ещё раз похвастаться беспримерными своими познаниями, сделав следующий шаг, объяснив тому анониму с его верой в джамптейблы, как ко всему что ты описываешь применимы JIT и PGO оптимизации.

Ответить | Правка | Наверх | Cообщить модератору

37. "Для Python предложен JIT-компилятор, использующий технику co..."  +1 +/
Сообщение от all_glory_to_the_hypnotoad (ok), 26-Дек-23, 17:40 
JIT жрёт память и добавляет внезапные лаги. Так что лучше иметь стабильный по задержкам, но чуть менее производительный код, чем JIT со всеми его минусами. Ну или иметь возможность включать JIT только для определённых функций/модуля
Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

40. "Для Python предложен JIT-компилятор, использующий технику co..."  +/
Сообщение от Вы забыли заполнить поле Name (?), 26-Дек-23, 17:51 
> JIT жрёт память и добавляет внезапные лаги. Так что лучше иметь стабильный
> по задержкам, но чуть менее производительный код, чем JIT со всеми
> его минусами. Ну или иметь возможность включать JIT только для определённых
> функций/модуля

Вроде как в нормальных компиляторах jit не всегда задействуется. Там несколько этапов от простого интерпретатора байткода до полноценного jit. В зависимости от статистики происходит переключение между ними. По крайней мере так сделано в v8 и так планируют делать в python

Ответить | Правка | Наверх | Cообщить модератору

83. "Для Python предложен JIT-компилятор, использующий технику co..."  –1 +/
Сообщение от Аноньимъ (ok), 27-Дек-23, 00:56 
Лучше только в системах реального времени.
А вообще, нет, не лучше.

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

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

86. "Для Python предложен JIT-компилятор, использующий технику co..."  +2 +/
Сообщение от Аноним (86), 27-Дек-23, 02:46 
> Лучше только в системах реального времени.
> А вообще, нет, не лучше.
> И нормальный джит отрабатывает один раз, после чего все летает без всяких
> задержек.
> Пример жава и дотнет. Особенно последний, потому как оно в ровень с
> нативным кодом может.

Особенно это видно на тормозящих играх на unity

Ответить | Правка | Наверх | Cообщить модератору

89. "Для Python предложен JIT-компилятор, использующий технику co..."  +/
Сообщение от Аноньимъ (ok), 27-Дек-23, 02:55 
Что угодно на чём угодно может тормозить. По самым разным причинам.
Ответить | Правка | Наверх | Cообщить модератору

96. "Для Python предложен JIT-компилятор, использующий технику co..."  –1 +/
Сообщение от all_glory_to_the_hypnotoad (ok), 27-Дек-23, 03:41 
Но тут по вполне конкретным причинам, которых нет у других ЯП. Например, из-за GC. Хотя может и из-за JIT тоже. В итоге никакого 'в ровень' не получается.
Ответить | Правка | Наверх | Cообщить модератору

118. "Для Python предложен JIT-компилятор, использующий технику co..."  +/
Сообщение от Аноньимъ (ok), 27-Дек-23, 16:59 
> Но тут по вполне конкретным причинам, которых нет у других ЯП. Например,
> из-за GC. Хотя может и из-за JIT тоже. В итоге никакого
> 'в ровень' не получается.

GC в ЯП никаких нет.

Получается не только лишь в ровень, если руки прямые.

Но никогда не будет с дотнетом и шарпом в ровень идти хоть сишка хоть сипипишка которая туже сложность со всеми необходимыми проверками и защитами реализует.

Ответить | Правка | Наверх | Cообщить модератору

128. "Для Python предложен JIT-компилятор, использующий технику co..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok), 28-Дек-23, 02:14 
> Получается не только лишь в ровень, если руки прямые - настлько древняя мантра, что в 2023 даже уже не смешно
Ответить | Правка | Наверх | Cообщить модератору

97. "Для Python предложен JIT-компилятор, использующий технику co..."  –1 +/
Сообщение от all_glory_to_the_hypnotoad (ok), 27-Дек-23, 03:43 
Лучше, например, в питоне, он тормозит равномерно. И в компилируемых ЯП вроде с++
Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

119. "Для Python предложен JIT-компилятор, использующий технику co..."  +/
Сообщение от Аноньимъ (ok), 27-Дек-23, 17:01 
В Питоне глобальный лок всё ещё никуда не делся.
То как тормозит питон математикой не описать, нужно индусов звать танец танцевать.
Ответить | Правка | Наверх | Cообщить модератору

129. "Для Python предложен JIT-компилятор, использующий технику co..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok), 28-Дек-23, 02:19 
Есть, так не трогай его. Основная часть питонячего кода это однопоточные приложения. И пишу же про равномерность торможения, а не про просто торможение. Например, в тестах сервис длительно показывает хорошие персентили по задржкам, а в проде спустя большой uptime внезапно просаживается условный 99-ый ... потому что что-то потекло и GC зафрагментировал память и начал лютовать когда ему вздумается. В стандартном питоне такого нет. В Java и JS постоянно, особенно это хорошо заметно по браузерам.
Ответить | Правка | Наверх | Cообщить модератору

44. "Для Python предложен JIT-компилятор, использующий технику co..."  –2 +/
Сообщение от _kp (ok), 26-Дек-23, 18:16 
В теории, если считать скорость постоянной перекопиляции пренебрежимо мала, то есть когда задержка не заметна, и раздражает пользователя.
А для пользователя не нативное приложение - неполноценное приложение.
Ведь никто в здравом уме не поставит что то типа VsCode по умолчанию вместо нотепада как редактор по умолчанию.

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


Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

59. "Для Python предложен JIT-компилятор, использующий технику co..."  –2 +/
Сообщение от BrainFucker (ok), 26-Дек-23, 20:25 
> Так бы и написали что компиляцию в нативный код не осилили, ибо из за динамической типизации все равно фигня с производительностью.

В будущем сделают компиляцию в машинный код с помощью нейросетей. А так как ресурсов для запуска такого компилятора локально ни у кого е будет, она будет облачной.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

77. "Для Python предложен JIT-компилятор, использующий технику co..."  +/
Сообщение от _kp (ok), 27-Дек-23, 00:34 

> В будущем сделают компиляцию в машинный код с помощью нейросетей.

Пока сподобятся, с этим справится процессор от уного чайника, или рак на горе свиснет.

> как ресурсов для запуска такого компилятора локально ни у кого не будет

Ресурсов достаточно и сейчас, но у кого то компиляция чего то рпзмером с Хрлма займет минуты, у кого то пол-дня, и более.
Но, если например у игрушки от компиляции в нативный код  fps возрастет хотя бы вдвое, то есть смысл даже в компилчции на бюджетном сиартфоне. Да пусть он хоть три дня пыхтит, играть то поболее придется.

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

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

>> будет облачной.

Не будет, ибо и не выгодно, и на быстром компе тупо быстрее переаомпилировать самому, чем закачать и выкачать.
А вот репозитории, это да, им компилировать обновляемое ПО в нативные бинарникпи, самое то.

Ответить | Правка | Наверх | Cообщить модератору

81. "Для Python предложен JIT-компилятор, использующий технику co..."  +/
Сообщение от Аноньимъ (ok), 27-Дек-23, 00:41 
Фигня с производительностью не от динамической типизации там от слова совсем.
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

87. "Для Python предложен JIT-компилятор, использующий технику co..."  +1 +/
Сообщение от Аноним (86), 27-Дек-23, 02:51 
> Фигня с производительностью не от динамической типизации там от слова совсем.

От чего же?

Ответить | Правка | Наверх | Cообщить модератору

113. "Для Python предложен JIT-компилятор, использующий технику co..."  +/
Сообщение от _kp (ok), 27-Дек-23, 10:55 
> Фигня с производительностью не от динамической типизации

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

В тех же Java и C#, код без дергатни памяти, то есть в критичных местах, получается очень быстрый без плясок с бубнамм, хотя там и нативного кода в полноценном смысле вовсе нет. И вполне логично подумать именно на типизацию в Питоне.


Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

117. "Для Python предложен JIT-компилятор, использующий технику co..."  +/
Сообщение от Аноньимъ (ok), 27-Дек-23, 16:51 
Ну вот и думают.
Аннотацию типов добавили уже давно. Очень удобно. Осталось оптимизацию кода сделать который тайпчекается.

И я не в курсе что там у них с автовыводом типов.

В Ракете прикольно сделали типизированную версию.

Ответить | Правка | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру