The OpenNET Project / Index page

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

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

26.12.2023 13:20

Брандт Букер (Brandt Bucher) из компании Microsoft, входящий в число core-разработчиков CPython и работающий в команде, занимающейся увеличением производительности интерпретатора CPython, опубликовал реализацию JIT-компилятора для Python, использующую технику Copy-and-Patch. Публикация JIT приурочена к Рождеству и анонс написан в стихах.

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

Работа метода Copy-and-Patch основывается на том, что релокация кода в памяти при загрузке компоновщиком объектных файлов и подстановка машинных инструкций вместо байткода в JIT, являются сходными задачами. При работе JIT в процессе выполнения программы осуществляется перебор созданных интерпретатором инструкций байткода и копирование для каждой инструкции заранее скомпилированного машинного кода в область памяти с исполняемым кодом, а также изменение на лету инструкций для подстановки в них обрабатываемых данных (JIT копирует готовые шаблоны уже скомпилированных функций и подставляет в них необходимые значения, такие как аргументы и константы). При загрузке объектных файлов также осуществляется копирование машинного кода в память и подстановка внешних символов.

В Copy-and-Patch JIT при помощи LLVM собирается объектный файл в формате ELF, содержащий данные об инструкциях байткода и информацию о необходимой замене данных. JIT заменяет сгенерированные в ходе интерпретации программы инструкции байткода на представления в машинном коде, попутно подставляя необходимые для вычислений данные. Реализация JIT требует в качестве зависимости LLVM на этапе сборки, но runtime-компоненты не привязаны к внешним зависимостям и сводятся примерно к 300 вручную написанным строкам на языке Си и 3000 сгенерированным строкам кода на Си.

По сравнению с традиционным JIT-инструментарием (LLVM -O0) предложенный JIT обеспечивает в 100 раз более быструю генерацию кода и на 15% более быстрый результирующий код. По сравнению с компиляцией в WebAssembly (Liftoff) новый JIT генерирует код в 5 раз быстрее, а результирующий код работает на 50% быстрее. Если сравнивать новый JIT с оптимизирующим JIT (LuaJIT), использующим вручную написанный код на ассемблере, то предложенный вариант оказался быстрее в 13 из 44 тестах, а в среднем отстал по производительности на 35%, при существенном упрощении сопровождения и уменьшении уровня сложности реализации.



  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: В JIT-компиляторе Pyston-lite реализована поддержка Python 3.10
  3. OpenNews: DeepMind открыл код S6, библиотеки с реализацией JIT-компилятора для CPython
  4. OpenNews: Проект Pyston, предлагающий Python с JIT-компилятором, вернулся к открытой модели разработки
  5. OpenNews: Представлен HOPE, JIT-компилятор для языка Python, транслирующий в C++
  6. OpenNews: Выпуск RustPython 0.3, реализации интерпретатора Python на языке Rust
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/60352-python
Ключевые слова: python, jit, compile
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (103) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 14:28, 26/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    > runtime-компоненты сводятся примерно к 300 вручную написанным строкам на языке Си и 3000 сгенерированным строкам кода на Си.

    Интересно, сколько дыр будет в этих 300 строках?

     
     
  • 2.48, Аноним (48), 18:31, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +9 +/
    В ненаписанных 300 строках кода дыр точно не будет.
     
  • 2.73, mister_0 (?), 23:58, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    frama-c и не будет ни одной
     

  • 1.3, Аноним (3), 14:35, 26/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Помнится Google все пыталась как-то ускорить Python, проекты делалЮ работников напрягал. Потом плюнули на это неблагодарное дело и создали Go. Теперь вот Microsoft что-то пытается сделать там, где это не особо легко by-design. Лично я жду mojo на посмотреть, что они там сделают.
     
     
  • 2.4, Аноним (4), 14:45, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • –8 +/
    Гугл никогда ничего не сделал за всю свою историю, так что не удивительно. Да и успехи мс с питоном всё наглядно демонстрируют.
     
     
  • 3.11, ebpfsfan (?), 15:15, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • –8 +/
    ога, половина интернета в котором ты сидишь сделана гуглом, все так
     
     
  • 4.15, Аноним (4), 15:19, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +7 +/
    >сделана гуглом

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

    вообще, разработка софта там явно не в приоритете

     
     
  • 5.67, C00l_ni66a (ok), 22:10, 26/12/2023 Скрыто ботом-модератором     [к модератору]
  • +1 +/
     
  • 4.23, Пряник (?), 15:58, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да? Они Apache/Nginx/PHP/MySQL/Postfix написали?
     
     
  • 5.29, Аноним (29), 16:05, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет, но гугл сделал ASP.NET MVC.
     
     
  • 6.120, Илья (??), 17:01, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    ASP net MVC amazon сделали же.
     
     
  • 7.126, амоним (?), 00:31, 28/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    вот врете. это старая разработка фейсбука
     
  • 2.5, Tron is Whistling (?), 14:47, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А получилось только у фейсбука с PHP - HHVM. Но потом идеи затянули в PHP 7 и 8, и HHVM тоже стал не нужен.
     
  • 2.21, Вы забыли заполнить поле Name (?), 15:54, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Google сделал v8, так что ускорять они умеют. Ты говоришь про https://github.com/google-deepmind/s6 ? Ну есть numba в замену к нему.

    Более того есть другие технологии, тот же https://github.com/facebookincubator/cinder

    В ядре питона уже поняли что нужно ускорять и занимаются этим, хотя пока до внедрения жита не дошло, но это в планах https://github.com/faster-cpython/ideas

    Кстати, pyston на практике не так сильно повышает производительность в отличие от pypy

    Что касается go, то это другой язык.

     
  • 2.41, Легивон (?), 17:57, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что есть tradeoff между достигаемой скоростью и возможностью интеграции с любыми внешними окружениями.
    Никого почему-то не смущает что все ML работает на таком медленном питоне. Возможности по интеграции могут быть гораздо важнее скорости числодробления (последним можно кстати заниматься на numpy и т.п. с такими же сишными скоростями)
    А вот с js получилось прямо забавно. Ведь удалось достигнуть и правда запредельных результатов. А потом... потом они просто взяли и отдали свой сверх остный инструмент самым ущербным мартышкам. И что толку? Браузер всеравно тормозит ровно настолько, чтобы страницы хоть как-то открывались. Ничего бы и не изменилось будь в client side скриптинге медленный питон.
     
     
  • 3.50, Витюшка (?), 18:34, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Только тут они написали говнокод и выйграли (заработали на этом), а в другом случае бы так не получилось.
     
     
  • 4.60, Легивон (?), 20:34, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Тоесть вы хотите сказать, что до появления js в вебе сайтов не было?
    Или что если бы не было client side скриптинга сайты были бы хуже?
     
     
  • 5.130, Советский инженер (ok), 11:03, 30/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >Или что если бы не было client side скриптинга сайты были бы хуже?

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

     
     
  • 6.131, Легивон (?), 16:01, 30/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это бред Во-первых контр пример магазины существовали до засилья js в вебе Во... большой текст свёрнут, показать
     
  • 3.74, Аноним (74), 00:04, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >  все ML работает на таком медленном питоне

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

     
  • 2.55, Аноним (55), 19:36, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще-то у Go корни древнее вашего этого питона. Гугли историю, в том числе plan9.

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

    Гуглу это надо было чтоб заменить легаси на сях и плюсах.

     
     
  • 3.69, Витюшка (?), 22:39, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • –4 +/
    И при этом "какой-то" пацан из универа, которому надоело кодить потом на С++ написал самый передовой язык программирования из всех, которые я знаю.

    Который гораздо лучше Go, хотя бы в обработке ошибок.

    А знаю я около 20 языков программирования. И это первая и единственная реальная замена чистому С.

    У Go есть своя ниша, наверное очень неплохой был язык для своего времени. Но garbage collection сразу определил его место в истории.

     
     
  • 4.108, leap42 (ok), 09:26, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Который гораздо лучше Go, хотя бы в обработке ошибок.

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

     
     
  • 5.111, Витюшка (?), 10:17, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ты о чём вообще? Не осилил прочитать комментарий и бросился печатать ответ как увидел слово С++?

    При чём тут исключения?
    В Zig вообще нет никаких исключений.

     
  • 5.125, Аноним (125), 22:06, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    С исключениями в многопоточных приложениях все точно также, как и с неисключения... большой текст свёрнут, показать
     
  • 2.72, th3m3 (ok), 23:40, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >жду mojo на посмотреть, что они там сделают.

    Mojo уже можно смотреть и писать. Они всё выложили.

     
     
  • 3.85, Аноним (3), 01:11, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да знаю я. У них даже онлайн среда есть для "попробовать" - https://playground.modular.com/
    Но времени пока нет. В предыдущий раз как пробовал все было сыровата и в глубокой альфе.
    Еще вопрос волнует - не сделают ли они при релизе платным mojo или с какими-либо ограничениями в бесплатной версии.
     
     
  • 4.127, Аноним (3), 01:52, 28/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вот тут статейка на Хабре подоспела по поводу сравнения производительности Mojo с С+++ библиотеками. Вывод: Mojo лучшим пока проигрыват, но не сильно (а чистый Python уделает как тузик грелку)

    https://habr.com/ru/articles/783138/

     

  • 1.6, Аноним (6), 14:55, 26/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    >При работе 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.

     
     
  • 2.7, Аноним (7), 15:06, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Все регистры пришлось сохранять ещё потому, что на максимальных флагах защиты от... большой текст свёрнут, показать
     
     
  • 3.9, Аноним (9), 15:11, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Ты =очень= крутой, аноним.

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

     
     
  • 4.13, Аноним (13), 15:17, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А никто и не заставляет :). Кушайте Растишку.
     
     
  • 5.42, Аноним (9), 18:02, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чем больше я понимаю ЯП и учу Схему, тем больше пишу на баше.
     
  • 4.14, Аноним (14), 15:19, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И я не крутой. Я просто перфекционист.
     
     
  • 5.43, YetAnotherOnanym (ok), 18:05, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я так понимаю, если тебя вовремя не остановить, ты дойдёшь до того, что всю computationslly-heavy функциональность запихнёшь в fpga'шку.
     
     
  • 6.76, x3who (?), 00:29, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Я так понимаю, если тебя вовремя не остановить, ты дойдёшь до того, что всю computationslly-heavy функциональность запихнёшь в fpga'шку.

    Чот вот это не пахнет даже минимизацией и переводом в базис FPGA-шкинскиких LU: "сгенерировав экспоненциально много функций силами компилятора"

     
  • 4.38, Вы забыли заполнить поле Name (?), 17:40, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Ты =очень= крутой, аноним.
    > Но пользоваться твоей программой я, конечно, не буду.

    Если она есть вообще.

     
  • 3.25, Аноним (25), 16:01, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    а что делает твой софт?
     
     
  • 4.31, Аноним (31), 16:34, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Когда доделаю - на опеннете может появиться анонс. А пока - "ничего".
     
     
  • 5.32, pavlinux (ok), 16:58, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Приз за лучший "Коммент Года 2023"!  
     
  • 5.70, Аноним (70), 22:44, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Тогда подождём. А пока - "НЕ НУЖНО".
     
  • 5.115, Аноним (115), 12:50, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    "На словах я Лев Толстой, а не деле..."
    Всё как обычно)
     
  • 2.10, Аноним (10), 15:14, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >сохранять на стеке

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

     
     
  • 3.79, Аноньимъ (ok), 00:39, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И как оно работает в многопотоке?
     
     
  • 4.90, Аноним (90), 02:55, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Отлично.
     
  • 2.22, Проходил мимо (?), 15:57, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по описанию, вами была проделана впечатляющая работа. Но у меня, после прочитанного, создалось впечатление, что проще было бы критичное по скорости ядро "движка" сразу писать на ассемблере, а на всем остальном делать только высокоуровневую обвязку.
     
     
  • 3.30, Аноним (30), 16:13, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не, clang генерит быстрый код, когда часть из входных данных захардкодожена.
     
  • 2.28, Пряник (?), 16:04, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это та самая борьба с компилятором, которую вылечили в расте?
     
  • 2.36, Витюшка (?), 17:37, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Выглядит очень интересно, как минимум много умных услов)

    А что за проект? Язык программирования? Что он вообще делает?

    Хобби? Работа? Наука?
    Публикации есть?

    Я в этом не силён. Но Zig позволяет тебе выбирать calling convention для каждой функции.

    callconv(WINAPI)
    callconv(.Inline)
    callconv(.Naked)
    callconv(.C)

    Наверное ещё что-то. Много оптимизаций встроено в язык.

    Писать compile time код - это просто песня. Generic код тоже.

    Есть ассемблерные вставки в языке (из коробки).

    Можно вызывать С код и С++.
    Можно даже С++ код компилировать компилятором Zig! Те просто берёшь и компилируешь свой С++, а потом добавляешь Zig потихоньку. Переписывать всё не нужно.

    Для твоей задач подходит идеально.
    Быстрее чем на Zig уже не будет.

     
     
  • 3.47, Аноним (47), 18:29, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >Но Zig позволяет тебе выбирать calling convention для каждой функции.

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

     
     
  • 4.78, Аноньимъ (ok), 00:37, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Стек типо в кеше не присутствует?
     
     
  • 5.92, Аноним (90), 03:03, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Присутствует, так как иногда приходится дёргать. Но основные обращения к памяти - это считывание данных и запись результатов.
     
  • 4.80, x3who (?), 00:39, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > ненужные перебросы из одних регистров в другие с сохранениями состояния caller-saved на стеке.

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

     
     
  • 5.95, Аноним (90), 03:20, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    У компилятора есть причины её не инлайнить - она виртуальная. Остаётся thiscallом её вызывать. А thiscall - это конкретная конвенция, а поддержки кастомных конвенций увы нет.
     

  • 1.8, Аноним (8), 15:07, 26/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Ускоряют питон, а он все не ускоряется
     
     
  • 2.19, sig11 (ok), 15:45, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Кто сказал, что ускоряют?
    "а в среднем отстал по производительности на 35%,"
     
  • 2.114, Аноним (114), 12:39, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://opennet.ru/59641-python
     

  • 1.12, _kp (ok), 15:17, 26/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    JIT - это лишние тормоза, считай полумеры.
    Так бы и написали что компиляцию в нативный код не осилили, ибо из за динамической типизации все равно фигня с производительностью.
     
     
  • 2.33, Bottle (?), 17:04, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    JIT потенциально обладает преимуществом перед обычной компиляцией. Вот есть у тебя куча ветвлений switch-case в коде, профилировщик собирает статистику и на основе этого компилирует код так, чтобы первыми проверялись самые частые case'ы.
    Это, к слову, также положено в основу PGO.
     
     
  • 3.35, Аноним (35), 17:16, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ты с if/else не попутал?

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

     
     
  • 4.46, Bottle (?), 18:27, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Семантически switch-case и if-else одинаковы, современные компиляторы их разворачивают в одинаковые инструкции 100%. Это раньше могли быть приколы вида того, что for(;;) и while(true) преобразовались в разные ассемблерных инструкции.
     
     
  • 5.52, Аноним (52), 19:04, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вы путаете обычный switch и switch с паттерн матчингом. Для обычного свитча компилятор собирает lookup табличку, в которой jmp на нужную ветку идёт даже без cmp инструкций. А вот паттерн матчинг разворачивается в обычные if со всеми вытекающими
     
     
  • 6.82, Аноньимъ (ok), 00:47, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это исключительно зависит от конкретного ЯП.
    Что там будет вкомпилировпнно и или выполненно в итоге.
    Ифы тоже можно в jmp развернуть.

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

     
  • 5.53, Аноним (35), 19:10, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Что ты, блин, несёшь? Ты сам то проверял? Ничего там не одинаково.
     
  • 4.54, Аноним (-), 19:28, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это если у тебя switch по перечисляемому+упорядочиваемому типу, и если используется непрерывный диапазон значений этого типа. Попробуй создать джамптабличку для:

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

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

     
     
  • 5.57, all_glory_to_the_hypnotoad (ok), 20:22, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Для первого куска делаешь таблицу с null-дырками, для второго обычное дерево или вообще линейный поиск если case-ов мало. А как оно будет на самом деле зависит от компилятора, так-то некоторые и эквивалентный каскад из if-ов умеют в таблицу упаковывать.
     
     
  • 6.61, Аноним (-), 20:55, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Умница дочка!

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

     
  • 3.37, all_glory_to_the_hypnotoad (ok), 17:40, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    JIT жрёт память и добавляет внезапные лаги. Так что лучше иметь стабильный по задержкам, но чуть менее производительный код, чем JIT со всеми его минусами. Ну или иметь возможность включать JIT только для определённых функций/модуля
     
     
  • 4.40, Вы забыли заполнить поле Name (?), 17:51, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > JIT жрёт память и добавляет внезапные лаги. Так что лучше иметь стабильный
    > по задержкам, но чуть менее производительный код, чем JIT со всеми
    > его минусами. Ну или иметь возможность включать JIT только для определённых
    > функций/модуля

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

     
  • 4.83, Аноньимъ (ok), 00:56, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Лучше только в системах реального времени.
    А вообще, нет, не лучше.

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

     
     
  • 5.86, Аноним (86), 02:46, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Лучше только в системах реального времени.
    > А вообще, нет, не лучше.
    > И нормальный джит отрабатывает один раз, после чего все летает без всяких
    > задержек.
    > Пример жава и дотнет. Особенно последний, потому как оно в ровень с
    > нативным кодом может.

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

     
     
  • 6.89, Аноньимъ (ok), 02:55, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Что угодно на чём угодно может тормозить. По самым разным причинам.
     
     
  • 7.96, all_glory_to_the_hypnotoad (ok), 03:41, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Но тут по вполне конкретным причинам, которых нет у других ЯП. Например, из-за GC. Хотя может и из-за JIT тоже. В итоге никакого 'в ровень' не получается.
     
     
  • 8.118, Аноньимъ (ok), 16:59, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    GC в ЯП никаких нет Получается не только лишь в ровень, если руки прямые Но ни... текст свёрнут, показать
     
     
  • 9.128, all_glory_to_the_hypnotoad (ok), 02:14, 28/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Для Python предложен JIT-компилятор, использующий технику co...... текст свёрнут, показать
     
  • 5.97, all_glory_to_the_hypnotoad (ok), 03:43, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Лучше, например, в питоне, он тормозит равномерно. И в компилируемых ЯП вроде с++
     
     
  • 6.119, Аноньимъ (ok), 17:01, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В Питоне глобальный лок всё ещё никуда не делся.
    То как тормозит питон математикой не описать, нужно индусов звать танец танцевать.
     
     
  • 7.129, all_glory_to_the_hypnotoad (ok), 02:19, 28/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Есть, так не трогай его. Основная часть питонячего кода это однопоточные приложения. И пишу же про равномерность торможения, а не про просто торможение. Например, в тестах сервис длительно показывает хорошие персентили по задржкам, а в проде спустя большой uptime внезапно просаживается условный 99-ый ... потому что что-то потекло и GC зафрагментировал память и начал лютовать когда ему вздумается. В стандартном питоне такого нет. В Java и JS постоянно, особенно это хорошо заметно по браузерам.
     
  • 3.44, _kp (ok), 18:16, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    В теории, если считать скорость постоянной перекопиляции пренебрежимо мала, то есть когда задержка не заметна, и раздражает пользователя.
    А для пользователя не нативное приложение - неполноценное приложение.
    Ведь никто в здравом уме не поставит что то типа VsCode по умолчанию вместо нотепада как редактор по умолчанию.

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


     
  • 2.59, BrainFucker (ok), 20:25, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Так бы и написали что компиляцию в нативный код не осилили, ибо из за динамической типизации все равно фигня с производительностью.

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

     
     
  • 3.77, _kp (ok), 00:34, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Пока сподобятся, с этим справится процессор от уного чайника, или рак на горе св... большой текст свёрнут, показать
     
  • 2.81, Аноньимъ (ok), 00:41, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Фигня с производительностью не от динамической типизации там от слова совсем.
     
     
  • 3.87, Аноним (86), 02:51, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Фигня с производительностью не от динамической типизации там от слова совсем.

    От чего же?

     
  • 3.113, _kp (ok), 10:55, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Фигня с производительностью не от динамической типизации

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

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


     
     
  • 4.117, Аноньимъ (ok), 16:51, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот и думают.
    Аннотацию типов добавили уже давно. Очень удобно. Осталось оптимизацию кода сделать который тайпчекается.

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

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

     

  • 1.17, ИмяХ (ok), 15:41, 26/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    То есть питон сейчас стал в 100 раз быстрее?
     
     
  • 2.24, Аноним (24), 16:00, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В 100 раз быстрее jit генерация байткда, само исполнение стало быстрее на десятки процентов в лучшем случае.
     
  • 2.45, _kp (ok), 18:18, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > То есть питон сейчас стал в 100 раз быстрее?

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


     
     
  • 3.49, Аноним (48), 18:33, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Сделать транслятор типа TypePython с подсказками о типах для AST.
     
     
  • 4.122, Аноним (122), 18:49, 27/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Mypyc
     

  • 1.18, Аноним (18), 15:45, 26/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > и анонс написан в стихах

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

     
  • 1.39, YetAnotherOnanym (ok), 17:43, 26/12/2023 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +/
     

     ....ответы скрыты (4)

  • 1.65, Аноним (65), 21:48, 26/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    >Реализация JIT требует в качестве зависимости LLVM на этапе сборки

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

     
  • 1.75, Аноним (75), 00:29, 27/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кто прояснит — этот copy and patch чем-то отличается от AOT компиляции или это совсем что-то другое и я не в ту степь?
     
  • 1.84, Аноним (84), 01:02, 27/12/2023 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +/
     

  • 1.91, Аноним (86), 02:59, 27/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Фото на гитхабе у него забавное
     
  • 1.112, Аноним (112), 10:36, 27/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как оно будет работать при "monkey patching"?
     
  • 1.132, Аноним (132), 15:50, 31/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    JIT - дыра в безопасности которую M$ хотят вкорячить в питон.

    JIT  на безопасных платформах работать не будет никогда.

    JIT - зло которое надо искоренять!

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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