forum.opennet.ru - "Для Python предложен JIT-компилятор, использующий технику copy-and-patch" (103)

"Для Python предложен JIT-компилятор, использующий технику copy-and-patch"

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

"Для Python предложен JIT-компилятор, использующий технику copy-and-patch"	+/–
Сообщение от opennews (??), 26-Дек-23, 14:28
Брандт Букер (Brandt Bucher) из компании Microsoft, входящий в число core-разработчиков CPython и работающий команде, занимающейся увеличением производительности интерпретатора CPython, опубликовал реализацию JIT-компилятора для Python, использующую технику Copy-and-Patch. Публикация JIT приурочена к Рождеству и анонс написан в стихах... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60352
Ответить \| Правка \| Cообщить модератору

Оглавление

Интересно, сколько дыр будет в этих 300 строках , Аноним (-), 14:28 , 26-Дек-23, (1) –4

В ненаписанных 300 строках кода дыр точно не будет , Аноним (48), 18:31 , 26-Дек-23, (48) +9
frama-c и не будет ни одной, mister_0 (?), 23:58 , 26-Дек-23, (73) +1

Помнится Google все пыталась как-то ускорить Python, проекты делалЮ работников н, Аноним (3), 14:35 , 26-Дек-23, (3) +8

Гугл никогда ничего не сделал за всю свою историю, так что не удивительно Да и , Аноним (4), 14:45 , 26-Дек-23, (4) –8

ога, половина интернета в котором ты сидишь сделана гуглом, все так, ebpfsfan (?), 15:15 , 26-Дек-23, (11) –8

ты видимо хотел сказать куплена гуглом, какое отношение убитых продуктов к живым, Аноним (4), 15:19 , 26-Дек-23, (15) +7

Скрыто модератором, C00l_ni66a (ok), 22:10 , 26-Дек-23, (67) +1

Да Они Apache Nginx PHP MySQL Postfix написали , Пряник (?), 15:58 , 26-Дек-23, (23) +1

Нет, но гугл сделал ASP NET MVC , Аноним (29), 16:05 , 26-Дек-23, (29) +1

ASP net MVC amazon сделали же , Илья (??), 17:01 , 27-Дек-23, (120)

вот врете это старая разработка фейсбука, амоним (?), 00:31 , 28-Дек-23, (126)

А получилось только у фейсбука с PHP - HHVM Но потом идеи затянули в PHP 7 и 8,, Tron is Whistling (?), 14:47 , 26-Дек-23, (5) +2
Google сделал v8, так что ускорять они умеют Ты говоришь про https github com, Вы забыли заполнить поле Name (?), 15:54 , 26-Дек-23, (21) +2
Потому что есть tradeoff между достигаемой скоростью и возможностью интеграции с, Легивон (?), 17:57 , 26-Дек-23, (41)

Только тут они написали говнокод и выйграли заработали на этом , а в другом слу, Витюшка (?), 18:34 , 26-Дек-23, (50) –1

Тоесть вы хотите сказать, что до появления js в вебе сайтов не было Или что если, Легивон (?), 20:34 , 26-Дек-23, (60)

википедия была бы такой же,а вот всякие магазины и другие онлайнбанкинги не суще, Советский инженер (ok), 11:03 , 30-Дек-23, (130)

Это бред Во-первых контр пример магазины существовали до засилья js в вебе Во-в, Легивон (?), 16:01 , 30-Дек-23, (131)

На питуне там только бизнес логика Буквально обёртки сишных плюсовых функции , Аноним (74), 00:04 , 27-Дек-23, (74) +1

Вообще-то у Go корни древнее вашего этого питона Гугли историю, в том числе pla, Аноним (55), 19:36 , 26-Дек-23, (55)

И при этом какой-то пацан из универа, которому надоело кодить потом на С нап, Витюшка (?), 22:39 , 26-Дек-23, (69) –4

ахахаха, знаете, да, что комитет плюсецкого рассматривает уход от исключений в с, leap42 (ok), 09:26 , 27-Дек-23, (108)

Ты о чём вообще Не осилил прочитать комментарий и бросился печатать ответ как у, Витюшка (?), 10:17 , 27-Дек-23, (111)
С исключениями в многопоточных приложениях все точно также, как и с неисключения, Аноним (125), 22:06 , 27-Дек-23, (125)

Mojo уже можно смотреть и писать Они всё выложили , th3m3 (ok), 23:40 , 26-Дек-23, (72)

Да знаю я У них даже онлайн среда есть для попробовать - https playground m, Аноним (3), 01:11 , 27-Дек-23, (85)

Вот тут статейка на Хабре подоспела по поводу сравнения производительности Mojo , Аноним (3), 01:52 , 28-Дек-23, (127)

Стековая машина что-ли Я писал jit-компищятор на основе техники copy and patch , Аноним (6), 14:55 , 26-Дек-23, (6) +7

Все регистры пришлось сохранять ещё потому, что на максимальных флагах защиты от, Аноним (7), 15:06 , 26-Дек-23, (7) +5

Ты очень крутой, аноним Но пользоваться твоей программой я, конечно, не буду , Аноним (9), 15:11 , 26-Дек-23, (9) +8

А никто и не заставляет Кушайте Растишку , Аноним (13), 15:17 , 26-Дек-23, (13)

Чем больше я понимаю ЯП и учу Схему, тем больше пишу на баше , Аноним (9), 18:02 , 26-Дек-23, (42) +1

И я не крутой Я просто перфекционист , Аноним (14), 15:19 , 26-Дек-23, (14) +1

Я так понимаю, если тебя вовремя не остановить, ты дойдёшь до того, что всю comp, YetAnotherOnanym (ok), 18:05 , 26-Дек-23, (43) +1

Чот вот это не пахнет даже минимизацией и переводом в базис FPGA-шкинскиких LU , x3who (?), 00:29 , 27-Дек-23, (76)

Если она есть вообще , Вы забыли заполнить поле Name (?), 17:40 , 26-Дек-23, (38)

а что делает твой софт , Аноним (25), 16:01 , 26-Дек-23, (25)

Когда доделаю - на опеннете может появиться анонс А пока - ничего , Аноним (31), 16:34 , 26-Дек-23, (31) +7

Приз за лучший Коммент Года 2023 , pavlinux (ok), 16:58 , 26-Дек-23, (32) +5
Тогда подождём А пока - НЕ НУЖНО , Аноним (70), 22:44 , 26-Дек-23, (70) +3
На словах я Лев Толстой, а не деле Всё как обычно , Аноним (115), 12:50 , 27-Дек-23, (115)

Вообще сохранять на стеке очень тормознуто, горячий обрамляющий цикл сделан так,, Аноним (10), 15:14 , 26-Дек-23, (10)

И как оно работает в многопотоке , Аноньимъ (ok), 00:39 , 27-Дек-23, (79) –1

Отлично , Аноним (90), 02:55 , 27-Дек-23, (90)

Судя по описанию, вами была проделана впечатляющая работа Но у меня, после проч, Проходил мимо (?), 15:57 , 26-Дек-23, (22)

Не, clang генерит быстрый код, когда часть из входных данных захардкодожена , Аноним (30), 16:13 , 26-Дек-23, (30)

Это та самая борьба с компилятором, которую вылечили в расте , Пряник (?), 16:04 , 26-Дек-23, (28)
Выглядит очень интересно, как минимум много умных услов А что за проект Язык п, Витюшка (?), 17:37 , 26-Дек-23, (36)

Да де-факто стандартные расширения сишки тоже позволяют, но из приведённого вами, Аноним (47), 18:29 , 26-Дек-23, (47)

Стек типо в кеше не присутствует , Аноньимъ (ok), 00:37 , 27-Дек-23, (78)

Присутствует, так как иногда приходится дёргать Но основные обращения к памяти , Аноним (90), 03:03 , 27-Дек-23, (92)

Если такое есть без причины - то это копулятор лучше чинить Это же его сфера о, x3who (?), 00:39 , 27-Дек-23, (80)

У компилятора есть причины её не инлайнить - она виртуальная Остаётся thiscallо, Аноним (90), 03:20 , 27-Дек-23, (95)

Ускоряют питон, а он все не ускоряется, Аноним (8), 15:07 , 26-Дек-23, (8) +2

Кто сказал, что ускоряют а в среднем отстал по производительности на 35 , , sig11 (ok), 15:45 , 26-Дек-23, (19)
https opennet ru 59641-python, Аноним (114), 12:39 , 27-Дек-23, (114) +1

JIT - это лишние тормоза, считай полумеры Так бы и написали что компиляцию в нат, _kp (ok), 15:17 , 26-Дек-23, (12) –1

JIT потенциально обладает преимуществом перед обычной компиляцией Вот есть у те, Bottle (?), 17:04 , 26-Дек-23, (33) +4

Ты с if else не попутал switch case выстраивает jump table, там похер в каком по, Аноним (35), 17:16 , 26-Дек-23, (35) –2

Семантически switch-case и if-else одинаковы, современные компиляторы их развора, Bottle (?), 18:27 , 26-Дек-23, (46) +2

Вы путаете обычный switch и switch с паттерн матчингом Для обычного свитча комп, Аноним (52), 19:04 , 26-Дек-23, (52)

Это исключительно зависит от конкретного ЯП Что там будет вкомпилировпнно и или , Аноньимъ (ok), 00:47 , 27-Дек-23, (82)

Что ты, блин, несёшь Ты сам то проверял Ничего там не одинаково , Аноним (35), 19:10 , 26-Дек-23, (53) –1

Это если у тебя switch по перечисляемому упорядочиваемому типу, и если используе, Аноним (-), 19:28 , 26-Дек-23, (54)

Для первого куска делаешь таблицу с null-дырками, для второго обычное дерево или, all_glory_to_the_hypnotoad (ok), 20:22 , 26-Дек-23, (57)

Умница дочка Теперь ты можешь ещё раз похвастаться беспримерными своими познания, Аноним (-), 20:55 , 26-Дек-23, (61)

JIT жрёт память и добавляет внезапные лаги Так что лучше иметь стабильный по за, all_glory_to_the_hypnotoad (ok), 17:40 , 26-Дек-23, (37) +1

Вроде как в нормальных компиляторах jit не всегда задействуется Там несколько э, Вы забыли заполнить поле Name (?), 17:51 , 26-Дек-23, (40)
Лучше только в системах реального времени А вообще, нет, не лучше И нормальный д, Аноньимъ (ok), 00:56 , 27-Дек-23, (83) –1

Особенно это видно на тормозящих играх на unity, Аноним (86), 02:46 , 27-Дек-23, (86) +2

Что угодно на чём угодно может тормозить По самым разным причинам , Аноньимъ (ok), 02:55 , 27-Дек-23, (89)

Но тут по вполне конкретным причинам, которых нет у других ЯП Например, из-за G, all_glory_to_the_hypnotoad (ok), 03:41 , 27-Дек-23, (96) –1

GC в ЯП никаких нет Получается не только лишь в ровень, если руки прямые Но нико, Аноньимъ (ok), 16:59 , 27-Дек-23, (118)

Для Python предложен JIT-компилятор, использующий технику co..., all_glory_to_the_hypnotoad (ok), 02:14 , 28-Дек-23, (128)

Лучше, например, в питоне, он тормозит равномерно И в компилируемых ЯП вроде с , all_glory_to_the_hypnotoad (ok), 03:43 , 27-Дек-23, (97) –1

В Питоне глобальный лок всё ещё никуда не делся То как тормозит питон математико, Аноньимъ (ok), 17:01 , 27-Дек-23, (119)

Есть, так не трогай его Основная часть питонячего кода это однопоточные приложе, all_glory_to_the_hypnotoad (ok), 02:19 , 28-Дек-23, (129)

В теории, если считать скорость постоянной перекопиляции пренебрежимо мала, то е, _kp (ok), 18:16 , 26-Дек-23, (44) –2

В будущем сделают компиляцию в машинный код с помощью нейросетей А так как ресу, BrainFucker (ok), 20:25 , 26-Дек-23, (59) –2

Пока сподобятся, с этим справится процессор от уного чайника, или рак на горе св, _kp (ok), 00:34 , 27-Дек-23, (77)

Фигня с производительностью не от динамической типизации там от слова совсем , Аноньимъ (ok), 00:41 , 27-Дек-23, (81)

От чего же , Аноним (86), 02:51 , 27-Дек-23, (87) +1
Возможно, есть и другие причины, но невозможность на этапе компиляции сгенериров, _kp (ok), 10:55 , 27-Дек-23, (113)

Ну вот и думают Аннотацию типов добавили уже давно Очень удобно Осталось оптим, Аноньимъ (ok), 16:51 , 27-Дек-23, (117)

То есть питон сейчас стал в 100 раз быстрее , ИмяХ (ok), 15:41 , 26-Дек-23, (17)

В 100 раз быстрее jit генерация байткда, само исполнение стало быстрее на десятк, Аноним (24), 16:00 , 26-Дек-23, (24) +1
Нет, его отдельные операции стали быстрее, а в целом скорость примерно как была , _kp (ok), 18:18 , 26-Дек-23, (45)

Сделать транслятор типа TypePython с подсказками о типах для AST , Аноним (48), 18:33 , 26-Дек-23, (49)

Mypyc, Аноним (122), 18:49 , 27-Дек-23, (122)

а маска на презентации скучная не кожаная, Аноним (18), 15:45 , 26-Дек-23, (18) –1
Скрыто модератором, YetAnotherOnanym (ok), 17:43 , 26-Дек-23, (39)

Скрыто модератором, Аноним (48), 20:25 , 26-Дек-23, (58) –1

Скрыто модератором, Аноним (4), 23:09 , 26-Дек-23, (71)
Скрыто модератором, YetAnotherOnanym (ok), 13:00 , 27-Дек-23, (116) –1

Скрыто модератором, Аноним (66), 21:48 , 26-Дек-23, (66)

Оригинальный интерпретатор CPython, в том числе, тем и хорош, что никак не связа, Аноним (65), 21:48 , 26-Дек-23, (65) +3
Кто прояснит 8212 этот copy and patch чем-то отличается от AOT компиляции или, Аноним (75), 00:29 , 27-Дек-23, (75)
Скрыто модератором, Аноним (84), 01:02 , 27-Дек-23, (84)

Скрыто модератором, Аноним (86), 02:52 , 27-Дек-23, (88)

Фото на гитхабе у него забавное, Аноним (86), 02:59 , 27-Дек-23, (91)
Как оно будет работать при monkey patching , Аноним (112), 10:36 , 27-Дек-23, (112)
JIT - дыра в безопасности которую M хотят вкорячить в питон JIT на безопасных , Аноним (132), 15:50 , 31-Дек-23, (132)

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

1. "Для Python предложен JIT-компилятор, использующий технику co..." –4 +/–

Сообщение от Аноним (-), 26-Дек-23, 14:28

> runtime-компоненты сводятся примерно к 300 вручную написанным строкам на языке Си и 3000 сгенерированным строкам кода на Си.
Интересно, сколько дыр будет в этих 300 строках?

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

48. "Для Python предложен JIT-компилятор, использующий технику co..." +9 +/–

Сообщение от Аноним (48), 26-Дек-23, 18:31

В ненаписанных 300 строках кода дыр точно не будет.

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

73. "Для Python предложен JIT-компилятор, использующий технику co..." +1 +/–

Сообщение от mister_0 (?), 26-Дек-23, 23:58

frama-c и не будет ни одной

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

3. "Для Python предложен JIT-компилятор, использующий технику co..." +8 +/–

Сообщение от Аноним (3), 26-Дек-23, 14:35

Помнится Google все пыталась как-то ускорить Python, проекты делалЮ работников напрягал. Потом плюнули на это неблагодарное дело и создали Go. Теперь вот Microsoft что-то пытается сделать там, где это не особо легко by-design. Лично я жду mojo на посмотреть, что они там сделают.

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

4. "Для Python предложен JIT-компилятор, использующий технику co..." –8 +/–

Сообщение от Аноним (4), 26-Дек-23, 14:45

Гугл никогда ничего не сделал за всю свою историю, так что не удивительно. Да и успехи мс с питоном всё наглядно демонстрируют.

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

11. "Для Python предложен JIT-компилятор, использующий технику co..." –8 +/–

Сообщение от ebpfsfan (?), 26-Дек-23, 15:15

ога, половина интернета в котором ты сидишь сделана гуглом, все так

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

15. "Для Python предложен JIT-компилятор, использующий технику co..." +7 +/–

Сообщение от Аноним (4), 26-Дек-23, 15:19

>сделана гуглом
ты видимо хотел сказать куплена гуглом, какое отношение убитых продуктов к живым там сейчас?
вообще, разработка софта там явно не в приоритете

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

67. Скрыто модератором +1 +/–

Сообщение от C00l_ni66a (ok), 26-Дек-23, 22:10

>какое соотношение
https://killedbygoogle.com/

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

23. "Для Python предложен JIT-компилятор, использующий технику co..." +1 +/–

Сообщение от Пряник (?), 26-Дек-23, 15:58

Да? Они Apache/Nginx/PHP/MySQL/Postfix написали?

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

29. "Для Python предложен JIT-компилятор, использующий технику co..." +1 +/–

Сообщение от Аноним (29), 26-Дек-23, 16:05

Нет, но гугл сделал ASP.NET MVC.

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

120. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Илья (??), 27-Дек-23, 17:01

ASP net MVC amazon сделали же.

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

126. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от амоним (?), 28-Дек-23, 00:31

вот врете. это старая разработка фейсбука

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

5. "Для Python предложен JIT-компилятор, использующий технику co..." +2 +/–

Сообщение от Tron is Whistling (?), 26-Дек-23, 14:47

А получилось только у фейсбука с PHP - HHVM. Но потом идеи затянули в PHP 7 и 8, и HHVM тоже стал не нужен.

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

21. "Для Python предложен JIT-компилятор, использующий технику co..." +2 +/–

Сообщение от Вы забыли заполнить поле Name (?), 26-Дек-23, 15:54

Google сделал v8, так что ускорять они умеют. Ты говоришь про https://github.com/google-deepmind/s6 ? Ну есть numba в замену к нему.
Более того есть другие технологии, тот же https://github.com/facebookincubator/cinder
В ядре питона уже поняли что нужно ускорять и занимаются этим, хотя пока до внедрения жита не дошло, но это в планах https://github.com/faster-cpython/ideas
Кстати, pyston на практике не так сильно повышает производительность в отличие от pypy
Что касается go, то это другой язык.

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

41. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Легивон (?), 26-Дек-23, 17:57

Потому что есть tradeoff между достигаемой скоростью и возможностью интеграции с любыми внешними окружениями.
Никого почему-то не смущает что все ML работает на таком медленном питоне. Возможности по интеграции могут быть гораздо важнее скорости числодробления (последним можно кстати заниматься на numpy и т.п. с такими же сишными скоростями)
А вот с js получилось прямо забавно. Ведь удалось достигнуть и правда запредельных результатов. А потом... потом они просто взяли и отдали свой сверх остный инструмент самым ущербным мартышкам. И что толку? Браузер всеравно тормозит ровно настолько, чтобы страницы хоть как-то открывались. Ничего бы и не изменилось будь в client side скриптинге медленный питон.

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

50. "Для Python предложен JIT-компилятор, использующий технику co..." –1 +/–

Сообщение от Витюшка (?), 26-Дек-23, 18:34

Только тут они написали говнокод и выйграли (заработали на этом), а в другом случае бы так не получилось.

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

60. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Легивон (?), 26-Дек-23, 20:34

Тоесть вы хотите сказать, что до появления js в вебе сайтов не было?
Или что если бы не было client side скриптинга сайты были бы хуже?

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

130. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Советский инженер (ok), 30-Дек-23, 11:03

>Или что если бы не было client side скриптинга сайты были бы хуже?
википедия была бы такой же,
а вот всякие магазины и другие онлайнбанкинги не существовали бы.

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

131. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Легивон (?), 30-Дек-23, 16:01

> всякие магазины и другие онлайнбанкинги не существовали бы.
Это бред.
Во-первых контр пример: магазины существовали до засилья js в вебе.
Во-вторых: вы рассуждаете про отсутствие js полагая что без него браузеры не стали бы развиваться в сторону показа динамического контейнта. Это неверно, конечно они бы развивались дальше. Например показ пользователю вариантов дополнений введенного текста (например адреса) мог быть реализован стандартировано на уровне браузера специальным типом поля с указанием url куда отправлять ранее введенный текст для получения подсказки. Проверки правильности ввода - аналогично.
Веб мог быть гораздо более стандартизированным, понятным и управляемым если бы сиюминутные хотелки не победили. Но теперь его уже не удастся отрефакторить. Только бросить и сделать новый.

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

74. "Для Python предложен JIT-компилятор, использующий технику co..." +1 +/–

Сообщение от Аноним (74), 27-Дек-23, 00:04

>  все ML работает на таком медленном питоне
На питуне там только "бизнес логика". Буквально обёртки сишных/плюсовых функции типа "взять данные там", "передать данные туда", "сделать из этого конвейер", "посчитать".
Эсли бы бекенд этого добра был бы таки на питоне, то работало бы оно везде, с любыми видяхами и процами, только в миллион раз медленнее.

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

55. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (55), 26-Дек-23, 19:36

Вообще-то у Go корни древнее вашего этого питона. Гугли историю, в том числе plan9.
Гуглу повезло что оказались под боком спецы которые пуд соли съели на создании языков программирования, в Go затащили все самые лучшие решения за их жизнь.
Гуглу это надо было чтоб заменить легаси на сях и плюсах.

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

69. "Для Python предложен JIT-компилятор, использующий технику co..." –4 +/–

Сообщение от Витюшка (?), 26-Дек-23, 22:39

И при этом "какой-то" пацан из универа, которому надоело кодить потом на С++ написал самый передовой язык программирования из всех, которые я знаю.
Который гораздо лучше Go, хотя бы в обработке ошибок.
А знаю я около 20 языков программирования. И это первая и единственная реальная замена чистому С.
У Go есть своя ниша, наверное очень неплохой был язык для своего времени. Но garbage collection сразу определил его место в истории.

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

108. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от leap42 (ok), 27-Дек-23, 09:26

> Который гораздо лучше Go, хотя бы в обработке ошибок.
ахахаха, знаете, да, что комитет плюсецкого рассматривает уход от исключений в сторону обработки ошибок аля Go? если бы вы хоть один(!) раз написали серьёзный многопоточный проект, то знали бы что не так с исключениями, их обработкой и раскруткой стека при многопоточной нагрузке, но вы не знаете)

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

111. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Витюшка (?), 27-Дек-23, 10:17

Ты о чём вообще? Не осилил прочитать комментарий и бросился печатать ответ как увидел слово С++?
При чём тут исключения?
В Zig вообще нет никаких исключений.

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

125. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (125), 27-Дек-23, 22:06

> если бы вы хоть один(!) раз написали серьёзный многопоточный проект, то знали бы что не так с исключениями, их обработкой и раскруткой стека при многопоточной нагрузке,
С исключениями в многопоточных приложениях все точно также, как и с неисключениями в многопоточных приложениях... Дело в многопоточных приложениях, а не в исключениях.
В компиляторах/либах баги бывали, но вроде это фиксилось со временем. В mingw такой баг ~10 лет встречался. Примерно с 2009-го по 2018-й. Вообще, в 2010-м было пофикшено в апстриме mingw, но там смотря как именно mingw собирали и как часто тулчейн обновлялся. В Qt даже в 2018-м прям официально скачивалась версия с "глючным" mingw. А в ответе было "Qt не использует исключения, поэтому у нас всё работает... а вы страдайте ;)"
В виндовых сборках GLib/GTK аналогично получалось, но пофиксить удалось сильно быстрее.

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

72. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от th3m3 (ok), 26-Дек-23, 23:40

>жду mojo на посмотреть, что они там сделают.
Mojo уже можно смотреть и писать. Они всё выложили.

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

85. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (3), 27-Дек-23, 01:11

Да знаю я. У них даже онлайн среда есть для "попробовать" - https://playground.modular.com/
Но времени пока нет. В предыдущий раз как пробовал все было сыровата и в глубокой альфе.
Еще вопрос волнует - не сделают ли они при релизе платным mojo или с какими-либо ограничениями в бесплатной версии.

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

127. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (3), 28-Дек-23, 01:52

Вот тут статейка на Хабре подоспела по поводу сравнения производительности Mojo с С+++ библиотеками. Вывод: Mojo лучшим пока проигрыват, но не сильно (а чистый Python уделает как тузик грелку)
https://habr.com/ru/articles/783138/

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

6. "Для Python предложен JIT-компилятор, использующий технику co..." +7 +/–

Сообщение от Аноним (6), 26-Дек-23, 14:55

>При работе JIT в процессе выполнения программы осуществляется перебор созданных интерпретатором инструкций байткода и копирование для каждой инструкции заранее скомпилированного машинного кода в область памяти с исполняемым кодом, а также изменение на лету инструкций для подстановки в них обрабатываемых данных (JIT копирует готовые шаблоны уже скомпилированных функций и подставляет в них необходимые значения, такие как аргументы и константы). При загрузке объектных файлов также осуществляется копирование машинного кода в память и подстановка внешних символов.
Стековая машина что-ли? Я писал jit-компищятор на основе техники copy and patch. Было quick and dirty. Кончилось тем, что я это выкинул и написал x86-специфичный аллокатор регистров + энкодер инструкций (constexpr функции!) + constant size структуру для хранения инструкций + двухпроходный компилятор + кучу кода в inline assembly для интеграции отжитенного кода в остальную программу - все функции, вызываемые из горячего цикла пришлось в виде ассемблера в программу всунуть.
Пoтому что сишный и плюсовый код норовили заюзать регистры, которые я заюзал в jitе, зарезервировать их оказалось невозможно ни в gcc, ни в шланге (register type varName asm ("regName") не резервирует регистр!), сохранять на стеке перед каждым вызовом ВСЕ РЕГИСТРЫ (потому что компиляторы не имеют интерфейса, чтобы им сообщить свою calling convention для каждой функции и/или блока кода отдельно) ОЧЕНЬ тормознуто, при этом компилеро-сгенерированный код (по подстановкам в asm-блоках, не буду же я регистры напрямую юзать, это неудобно) не гнушался портить %rbp, поэтому пришлось всунуть его в clobber-list, теперь компилер орёт, что это deprecated.

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

7. "Для Python предложен JIT-компилятор, использующий технику co..." +5 +/–

Сообщение от Аноним (7), 26-Дек-23, 15:06

Все регистры пришлось сохранять ещё потому, что на максимальных флагах защиты от всех микроархитектурных уязвимостей компилер всё нулил при выходе из функции, не анализируя, откуда функция вызывается. Ещё очень неудобно вызывать функции из асм-кода. Приходртся самому всё класть на стэк. Изменяется прототип - всё насмарку, уследить за этим трудно. Зато у меня одна из самых быстрых программ. К сожалению пока неопубликована. У меня есть кое-какие идеи как этот джит выкинуть, сгенерировав экспоненциально много (а для этого нужно будет произвести большой поиск в графе состояний ветвями и границами, при этом результат гарантированно даст не очень большой показатель экспоненты, так что будет feasible) функций силами компилятора, шаблонов, constexpr и хардкода, а потом выбрав нужную. Если покажет производительрость наравне или выше джита - вообще джит выкину. Тогда и зарелижу.

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

9. "Для Python предложен JIT-компилятор, использующий технику co..." +8 +/–

Сообщение от Аноним (9), 26-Дек-23, 15:11

Ты =очень= крутой, аноним.
Но пользоваться твоей программой я, конечно, не буду.

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

13. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (13), 26-Дек-23, 15:17

А никто и не заставляет :). Кушайте Растишку.

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

42. "Для Python предложен JIT-компилятор, использующий технику co..." +1 +/–

Сообщение от Аноним (9), 26-Дек-23, 18:02

Чем больше я понимаю ЯП и учу Схему, тем больше пишу на баше.

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

14. "Для Python предложен JIT-компилятор, использующий технику co..." +1 +/–

Сообщение от Аноним (14), 26-Дек-23, 15:19

И я не крутой. Я просто перфекционист.

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

43. "Для Python предложен JIT-компилятор, использующий технику co..." +1 +/–

Сообщение от YetAnotherOnanym (ok), 26-Дек-23, 18:05

Я так понимаю, если тебя вовремя не остановить, ты дойдёшь до того, что всю computationslly-heavy функциональность запихнёшь в fpga'шку.

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

76. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от x3who (?), 27-Дек-23, 00:29

> Я так понимаю, если тебя вовремя не остановить, ты дойдёшь до того, что всю computationslly-heavy функциональность запихнёшь в fpga'шку.
Чот вот это не пахнет даже минимизацией и переводом в базис FPGA-шкинскиких LU: "сгенерировав экспоненциально много функций силами компилятора"

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

38. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Вы забыли заполнить поле Name (?), 26-Дек-23, 17:40

> Ты =очень= крутой, аноним.
> Но пользоваться твоей программой я, конечно, не буду.
Если она есть вообще.

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

25. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (25), 26-Дек-23, 16:01

а что делает твой софт?

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

31. "Для Python предложен JIT-компилятор, использующий технику co..." +7 +/–

Сообщение от Аноним (31), 26-Дек-23, 16:34

Когда доделаю - на опеннете может появиться анонс. А пока - "ничего".

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

32. "Для Python предложен JIT-компилятор, использующий технику co..." +5 +/–

Сообщение от pavlinux (ok), 26-Дек-23, 16:58

Приз за лучший "Коммент Года 2023"!

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

70. "Для Python предложен JIT-компилятор, использующий технику co..." +3 +/–

Сообщение от Аноним (70), 26-Дек-23, 22:44

Тогда подождём. А пока - "НЕ НУЖНО".

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

115. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (115), 27-Дек-23, 12:50

"На словах я Лев Толстой, а не деле..."
Всё как обычно)

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

10. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (10), 26-Дек-23, 15:14

>сохранять на стеке
Вообще сохранять на стеке очень тормознуто, горячий обрамляющий цикл сделан так, что стэк код вообще редко трогает и оптимизирован с помощью llvm-mca. Отjitенный код стек вообще не трогает, переходы туда и обратно jmpами, все аргументы в регистрах.

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

79. "Для Python предложен JIT-компилятор, использующий технику co..." –1 +/–

Сообщение от Аноньимъ (ok), 27-Дек-23, 00:39

И как оно работает в многопотоке?

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

90. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (90), 27-Дек-23, 02:55

Отлично.

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

22. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Проходил мимо (?), 26-Дек-23, 15:57

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

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

30. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (30), 26-Дек-23, 16:13

Не, clang генерит быстрый код, когда часть из входных данных захардкодожена.

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

28. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Пряник (?), 26-Дек-23, 16:04

Это та самая борьба с компилятором, которую вылечили в расте?

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

36. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Витюшка (?), 26-Дек-23, 17:37

Выглядит очень интересно, как минимум много умных услов)
А что за проект? Язык программирования? Что он вообще делает?
Хобби? Работа? Наука?
Публикации есть?
Я в этом не силён. Но Zig позволяет тебе выбирать calling convention для каждой функции.
callconv(WINAPI)
callconv(.Inline)
callconv(.Naked)
callconv(.C)
Наверное ещё что-то. Много оптимизаций встроено в язык.
Писать compile time код - это просто песня. Generic код тоже.
Есть ассемблерные вставки в языке (из коробки).
Можно вызывать С код и С++.
Можно даже С++ код компилировать компилятором Zig! Те просто берёшь и компилируешь свой С++, а потом добавляешь Zig потихоньку. Переписывать всё не нужно.
Для твоей задач подходит идеально.
Быстрее чем на Zig уже не будет.

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

47. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (47), 26-Дек-23, 18:29

>Но Zig позволяет тебе выбирать calling convention для каждой функции.
Да де-факто стандартные расширения сишки тоже позволяют, но из приведённого вами списка. При этом компилятор сгенерирует ненужные перебросы из одних регистров в другие с сохранениями состояния caller-saved на стеке. Мой код же стека касается в редких случаях - когда нужно выделить память. Тогда уже гулять-так гулять. Остальная свистопляска идёт в регистрах и кэше.

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

78. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноньимъ (ok), 27-Дек-23, 00:37

Стек типо в кеше не присутствует?

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

92. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (90), 27-Дек-23, 03:03

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

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

80. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от x3who (?), 27-Дек-23, 00:39

> ненужные перебросы из одних регистров в другие с сохранениями состояния caller-saved на стеке.
Если такое есть без причины - то это копулятор лучше чинить.. Это же его сфера ответственности!

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

95. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (90), 27-Дек-23, 03:20

У компилятора есть причины её не инлайнить - она виртуальная. Остаётся thiscallом её вызывать. А thiscall - это конкретная конвенция, а поддержки кастомных конвенций увы нет.

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

8. "Для Python предложен JIT-компилятор, использующий технику co..." +2 +/–

Сообщение от Аноним (8), 26-Дек-23, 15:07

Ускоряют питон, а он все не ускоряется

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

19. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от sig11 (ok), 26-Дек-23, 15:45

Кто сказал, что ускоряют?
"а в среднем отстал по производительности на 35%,"

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

114. "Для Python предложен JIT-компилятор, использующий технику co..." +1 +/–

Сообщение от Аноним (114), 27-Дек-23, 12:39

https://opennet.ru/59641-python

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

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ообщить модератору

17. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от ИмяХ (ok), 26-Дек-23, 15:41

То есть питон сейчас стал в 100 раз быстрее?

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

24. "Для Python предложен JIT-компилятор, использующий технику co..." +1 +/–

Сообщение от Аноним (24), 26-Дек-23, 16:00

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

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

45. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от _kp (ok), 26-Дек-23, 18:18

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

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

49. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (48), 26-Дек-23, 18:33

Сделать транслятор типа TypePython с подсказками о типах для AST.

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

122. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (122), 27-Дек-23, 18:49

Mypyc

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

18. "Для Python предложен JIT-компилятор, использующий технику co..." –1 +/–

Сообщение от Аноним (18), 26-Дек-23, 15:45

> и анонс написан в стихах
а маска на презентации скучная не кожаная

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

39. Скрыто модератором +/–

Сообщение от YetAnotherOnanym (ok), 26-Дек-23, 17:43

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

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

58. Скрыто модератором –1 +/–

Сообщение от Аноним (48), 26-Дек-23, 20:25

... и направляются прямиком к Cython.

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

71. Скрыто модератором +/–

Сообщение от Аноним (4), 26-Дек-23, 23:09

Реально кстати, у cython производительность 1 в 1 с си, при этом, оно выглядит как питон, и прозрачно интегрируется с питоном.

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

116. Скрыто модератором –1 +/–

Сообщение от YetAnotherOnanym (ok), 27-Дек-23, 13:00

cython.org:
> The Cython language is a superset of the Python language that additionally supports calling C functions and declaring C types on variables and class attributes
Так это си знать надо.

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

66. Скрыто модератором +/–

Сообщение от Аноним (66), 26-Дек-23, 21:48

> Те, кому надо, чтобы код быстро работал, обходят питон стороной
только ты об этом ничего не знаешь, так как не имеешь отношения ни тем, ни к другим

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

65. "Для Python предложен JIT-компилятор, использующий технику co..." +3 +/–

Сообщение от Аноним (65), 26-Дек-23, 21:48

>Реализация JIT требует в качестве зависимости LLVM на этапе сборки
Оригинальный интерпретатор CPython, в том числе, тем и хорош, что никак не связан с LLVM и полностью автономный.

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

75. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (75), 27-Дек-23, 00:29

Кто прояснит — этот copy and patch чем-то отличается от AOT компиляции или это совсем что-то другое и я не в ту степь?

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

84. Скрыто модератором +/–

Сообщение от Аноним (84), 27-Дек-23, 01:02

Блин, как я сюда попал сборище каких то диванные критиков, у python минус такой минус сякой да он и медленный и проще сделать так да сяк .... :DD  ну елы палы что за сборище ламеров, которые повторяют пойнты, которые были актуальны наверное в 90х для python 2, и нулевых ... просто рука лицо почти с каждого сообщения

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

88. Скрыто модератором +/–

Сообщение от Аноним (86), 27-Дек-23, 02:52

> Блин, как я сюда попал сборище каких то диванные критиков, у python
> минус такой минус сякой да он и медленный и проще сделать
> так да сяк .... :DD  ну елы палы что за
> сборище ламеров, которые повторяют пойнты, которые были актуальны наверное в 90х
> для python 2, и нулевых ... просто рука лицо почти с
> каждого сообщения
Потому что ничего не меняется сильно по скорости и потреблению памяти.

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

91. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (86), 27-Дек-23, 02:59

Фото на гитхабе у него забавное

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

112. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (112), 27-Дек-23, 10:36

Как оно будет работать при "monkey patching"?

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

132. "Для Python предложен JIT-компилятор, использующий технику co..." +/–

Сообщение от Аноним (132), 31-Дек-23, 15:50

JIT - дыра в безопасности которую M$ хотят вкорячить в питон.
JIT  на безопасных платформах работать не будет никогда.
JIT - зло которое надо искоренять!

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Для Python предложен JIT-компилятор, использующий технику co..."	–4 +/–
Сообщение от Аноним (-), 26-Дек-23, 14:28
> runtime-компоненты сводятся примерно к 300 вручную написанным строкам на языке Си и 3000 сгенерированным строкам кода на Си. Интересно, сколько дыр будет в этих 300 строках?
Ответить \| Правка \| Наверх \| Cообщить модератору


	48. "Для Python предложен JIT-компилятор, использующий технику co..."	+9 +/–
	Сообщение от Аноним (48), 26-Дек-23, 18:31
	В ненаписанных 300 строках кода дыр точно не будет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	73. "Для Python предложен JIT-компилятор, использующий технику co..."	+1 +/–
	Сообщение от mister_0 (?), 26-Дек-23, 23:58
	frama-c и не будет ни одной
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору

3. "Для Python предложен JIT-компилятор, использующий технику co..."	+8 +/–
Сообщение от Аноним (3), 26-Дек-23, 14:35
Помнится Google все пыталась как-то ускорить Python, проекты делалЮ работников напрягал. Потом плюнули на это неблагодарное дело и создали Go. Теперь вот Microsoft что-то пытается сделать там, где это не особо легко by-design. Лично я жду mojo на посмотреть, что они там сделают.
Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Для Python предложен JIT-компилятор, использующий технику co..."	–8 +/–
	Сообщение от Аноним (4), 26-Дек-23, 14:45
	Гугл никогда ничего не сделал за всю свою историю, так что не удивительно. Да и успехи мс с питоном всё наглядно демонстрируют.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Для Python предложен JIT-компилятор, использующий технику co..."	–8 +/–
	Сообщение от ebpfsfan (?), 26-Дек-23, 15:15
	ога, половина интернета в котором ты сидишь сделана гуглом, все так
	Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Для Python предложен JIT-компилятор, использующий технику co..."	+7 +/–
	Сообщение от Аноним (4), 26-Дек-23, 15:19
	>сделана гуглом ты видимо хотел сказать куплена гуглом, какое отношение убитых продуктов к живым там сейчас? вообще, разработка софта там явно не в приоритете
	Ответить \| Правка \| Наверх \| Cообщить модератору


	67. Скрыто модератором	+1 +/–
	Сообщение от C00l_ni66a (ok), 26-Дек-23, 22:10
	>какое соотношение https://killedbygoogle.com/
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Для Python предложен JIT-компилятор, использующий технику co..."	+1 +/–
	Сообщение от Пряник (?), 26-Дек-23, 15:58
	Да? Они Apache/Nginx/PHP/MySQL/Postfix написали?
	Ответить \| Правка \| К родителю #11 \| Наверх \| Cообщить модератору


	29. "Для Python предложен JIT-компилятор, использующий технику co..."	+1 +/–
	Сообщение от Аноним (29), 26-Дек-23, 16:05
	Нет, но гугл сделал ASP.NET MVC.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	120. "Для Python предложен JIT-компилятор, использующий технику co..."	+/–
	Сообщение от Илья (??), 27-Дек-23, 17:01
	ASP net MVC amazon сделали же.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	126. "Для Python предложен JIT-компилятор, использующий технику co..."	+/–
	Сообщение от амоним (?), 28-Дек-23, 00:31
	вот врете. это старая разработка фейсбука
	Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Для Python предложен JIT-компилятор, использующий технику co..."	+2 +/–
	Сообщение от Tron is Whistling (?), 26-Дек-23, 14:47
	А получилось только у фейсбука с PHP - HHVM. Но потом идеи затянули в PHP 7 и 8, и HHVM тоже стал не нужен.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	21. "Для Python предложен JIT-компилятор, использующий технику co..."	+2 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 26-Дек-23, 15:54
	Google сделал v8, так что ускорять они умеют. Ты говоришь про https://github.com/google-deepmind/s6 ? Ну есть numba в замену к нему. Более того есть другие технологии, тот же https://github.com/facebookincubator/cinder В ядре питона уже поняли что нужно ускорять и занимаются этим, хотя пока до внедрения жита не дошло, но это в планах https://github.com/faster-cpython/ideas Кстати, pyston на практике не так сильно повышает производительность в отличие от pypy Что касается go, то это другой язык.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	41. "Для Python предложен JIT-компилятор, использующий технику co..."	+/–
	Сообщение от Легивон (?), 26-Дек-23, 17:57
	Потому что есть tradeoff между достигаемой скоростью и возможностью интеграции с любыми внешними окружениями. Никого почему-то не смущает что все ML работает на таком медленном питоне. Возможности по интеграции могут быть гораздо важнее скорости числодробления (последним можно кстати заниматься на numpy и т.п. с такими же сишными скоростями) А вот с js получилось прямо забавно. Ведь удалось достигнуть и правда запредельных результатов. А потом... потом они просто взяли и отдали свой сверх остный инструмент самым ущербным мартышкам. И что толку? Браузер всеравно тормозит ровно настолько, чтобы страницы хоть как-то открывались. Ничего бы и не изменилось будь в client side скриптинге медленный питон.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


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


	60. "Для Python предложен JIT-компилятор, использующий технику co..."	+/–
	Сообщение от Легивон (?), 26-Дек-23, 20:34
	Тоесть вы хотите сказать, что до появления js в вебе сайтов не было? Или что если бы не было client side скриптинга сайты были бы хуже?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	130. "Для Python предложен JIT-компилятор, использующий технику co..."	+/–
	Сообщение от Советский инженер (ok), 30-Дек-23, 11:03
	>Или что если бы не было client side скриптинга сайты были бы хуже? википедия была бы такой же, а вот всякие магазины и другие онлайнбанкинги не существовали бы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	131. "Для Python предложен JIT-компилятор, использующий технику co..."	+/–
	Сообщение от Легивон (?), 30-Дек-23, 16:01
	> всякие магазины и другие онлайнбанкинги не существовали бы. Это бред. Во-первых контр пример: магазины существовали до засилья js в вебе. Во-вторых: вы рассуждаете про отсутствие js полагая что без него браузеры не стали бы развиваться в сторону показа динамического контейнта. Это неверно, конечно они бы развивались дальше. Например показ пользователю вариантов дополнений введенного текста (например адреса) мог быть реализован стандартировано на уровне браузера специальным типом поля с указанием url куда отправлять ранее введенный текст для получения подсказки. Проверки правильности ввода - аналогично. Веб мог быть гораздо более стандартизированным, понятным и управляемым если бы сиюминутные хотелки не победили. Но теперь его уже не удастся отрефакторить. Только бросить и сделать новый.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	74. "Для Python предложен JIT-компилятор, использующий технику co..."	+1 +/–
	Сообщение от Аноним (74), 27-Дек-23, 00:04
	> все ML работает на таком медленном питоне На питуне там только "бизнес логика". Буквально обёртки сишных/плюсовых функции типа "взять данные там", "передать данные туда", "сделать из этого конвейер", "посчитать". Эсли бы бекенд этого добра был бы таки на питоне, то работало бы оно везде, с любыми видяхами и процами, только в миллион раз медленнее.
	Ответить \| Правка \| К родителю #41 \| Наверх \| Cообщить модератору


	55. "Для Python предложен JIT-компилятор, использующий технику co..."	+/–
	Сообщение от Аноним (55), 26-Дек-23, 19:36
	Вообще-то у Go корни древнее вашего этого питона. Гугли историю, в том числе plan9. Гуглу повезло что оказались под боком спецы которые пуд соли съели на создании языков программирования, в Go затащили все самые лучшие решения за их жизнь. Гуглу это надо было чтоб заменить легаси на сях и плюсах.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	69. "Для Python предложен JIT-компилятор, использующий технику co..."	–4 +/–
	Сообщение от Витюшка (?), 26-Дек-23, 22:39
	И при этом "какой-то" пацан из универа, которому надоело кодить потом на С++ написал самый передовой язык программирования из всех, которые я знаю. Который гораздо лучше Go, хотя бы в обработке ошибок. А знаю я около 20 языков программирования. И это первая и единственная реальная замена чистому С. У Go есть своя ниша, наверное очень неплохой был язык для своего времени. Но garbage collection сразу определил его место в истории.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	108. "Для Python предложен JIT-компилятор, использующий технику co..."	+/–
	Сообщение от leap42 (ok), 27-Дек-23, 09:26
	> Который гораздо лучше Go, хотя бы в обработке ошибок. ахахаха, знаете, да, что комитет плюсецкого рассматривает уход от исключений в сторону обработки ошибок аля Go? если бы вы хоть один(!) раз написали серьёзный многопоточный проект, то знали бы что не так с исключениями, их обработкой и раскруткой стека при многопоточной нагрузке, но вы не знаете)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	111. "Для Python предложен JIT-компилятор, использующий технику co..."	+/–
	Сообщение от Витюшка (?), 27-Дек-23, 10:17
	Ты о чём вообще? Не осилил прочитать комментарий и бросился печатать ответ как увидел слово С++? При чём тут исключения? В Zig вообще нет никаких исключений.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	125. "Для Python предложен JIT-компилятор, использующий технику co..."	+/–
	Сообщение от Аноним (125), 27-Дек-23, 22:06
	> если бы вы хоть один(!) раз написали серьёзный многопоточный проект, то знали бы что не так с исключениями, их обработкой и раскруткой стека при многопоточной нагрузке, С исключениями в многопоточных приложениях все точно также, как и с неисключениями в многопоточных приложениях... Дело в многопоточных приложениях, а не в исключениях. В компиляторах/либах баги бывали, но вроде это фиксилось со временем. В mingw такой баг ~10 лет встречался. Примерно с 2009-го по 2018-й. Вообще, в 2010-м было пофикшено в апстриме mingw, но там смотря как именно mingw собирали и как часто тулчейн обновлялся. В Qt даже в 2018-м прям официально скачивалась версия с "глючным" mingw. А в ответе было "Qt не использует исключения, поэтому у нас всё работает... а вы страдайте ;)" В виндовых сборках GLib/GTK аналогично получалось, но пофиксить удалось сильно быстрее.
	Ответить \| Правка \| К родителю #108 \| Наверх \| Cообщить модератору


	72. "Для Python предложен JIT-компилятор, использующий технику co..."	+/–
	Сообщение от th3m3 (ok), 26-Дек-23, 23:40
	>жду mojo на посмотреть, что они там сделают. Mojo уже можно смотреть и писать. Они всё выложили.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	85. "Для Python предложен JIT-компилятор, использующий технику co..."	+/–
	Сообщение от Аноним (3), 27-Дек-23, 01:11
	Да знаю я. У них даже онлайн среда есть для "попробовать" - https://playground.modular.com/ Но времени пока нет. В предыдущий раз как пробовал все было сыровата и в глубокой альфе. Еще вопрос волнует - не сделают ли они при релизе платным mojo или с какими-либо ограничениями в бесплатной версии.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	127. "Для Python предложен JIT-компилятор, использующий технику co..."	+/–
	Сообщение от Аноним (3), 28-Дек-23, 01:52
	Вот тут статейка на Хабре подоспела по поводу сравнения производительности Mojo с С+++ библиотеками. Вывод: Mojo лучшим пока проигрыват, но не сильно (а чистый Python уделает как тузик грелку) https://habr.com/ru/articles/783138/
	Ответить \| Правка \| Наверх \| Cообщить модератору

6. "Для Python предложен JIT-компилятор, использующий технику co..."	+7 +/–
Сообщение от Аноним (6), 26-Дек-23, 14:55
>При работе JIT в процессе выполнения программы осуществляется перебор созданных интерпретатором инструкций байткода и копирование для каждой инструкции заранее скомпилированного машинного кода в область памяти с исполняемым кодом, а также изменение на лету инструкций для подстановки в них обрабатываемых данных (JIT копирует готовые шаблоны уже скомпилированных функций и подставляет в них необходимые значения, такие как аргументы и константы). При загрузке объектных файлов также осуществляется копирование машинного кода в память и подстановка внешних символов. Стековая машина что-ли? Я писал jit-компищятор на основе техники copy and patch. Было quick and dirty. Кончилось тем, что я это выкинул и написал x86-специфичный аллокатор регистров + энкодер инструкций (constexpr функции!) + constant size структуру для хранения инструкций + двухпроходный компилятор + кучу кода в inline assembly для интеграции отжитенного кода в остальную программу - все функции, вызываемые из горячего цикла пришлось в виде ассемблера в программу всунуть. Пoтому что сишный и плюсовый код норовили заюзать регистры, которые я заюзал в jitе, зарезервировать их оказалось невозможно ни в gcc, ни в шланге (register type varName asm ("regName") не резервирует регистр!), сохранять на стеке перед каждым вызовом ВСЕ РЕГИСТРЫ (потому что компиляторы не имеют интерфейса, чтобы им сообщить свою calling convention для каждой функции и/или блока кода отдельно) ОЧЕНЬ тормознуто, при этом компилеро-сгенерированный код (по подстановкам в asm-блоках, не буду же я регистры напрямую юзать, это неудобно) не гнушался портить %rbp, поэтому пришлось всунуть его в clobber-list, теперь компилер орёт, что это deprecated.
Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Для Python предложен JIT-компилятор, использующий технику co..."	+5 +/–
	Сообщение от Аноним (7), 26-Дек-23, 15:06
	Все регистры пришлось сохранять ещё потому, что на максимальных флагах защиты от всех микроархитектурных уязвимостей компилер всё нулил при выходе из функции, не анализируя, откуда функция вызывается. Ещё очень неудобно вызывать функции из асм-кода. Приходртся самому всё класть на стэк. Изменяется прототип - всё насмарку, уследить за этим трудно. Зато у меня одна из самых быстрых программ. К сожалению пока неопубликована. У меня есть кое-какие идеи как этот джит выкинуть, сгенерировав экспоненциально много (а для этого нужно будет произвести большой поиск в графе состояний ветвями и границами, при этом результат гарантированно даст не очень большой показатель экспоненты, так что будет feasible) функций силами компилятора, шаблонов, constexpr и хардкода, а потом выбрав нужную. Если покажет производительрость наравне или выше джита - вообще джит выкину. Тогда и зарелижу.
	Ответить \| Правка \| Наверх \| Cообщить модератору