Забавные новости 0й-Ti :)

Меня другое тут даже волнует - когда уже как грибы после дождя перестанут появляться проекты по наскипидаривания Пайтона на скорость?
Вроде мантру, что пайтон не для скорости, а для удобства уже всем в головы вдолбили.
Но куда тогда они все лезут? https://github.com/exaloop/codon

Какая то противоречивая ситуация - с одной стороны коммьюнити с пеной у рта доказывает, что скорости тут не надо, с другой пилит постоянно "всё более быстрые реализации".
Биполярочка какая-то...

 

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

 

В мире куча погромистов которые освоили кое как питухоний, но им сложно с С++, указатели им не нравятся, шаблоны. Вот и делают полностью проект на питуне, вот им и нужны всякие ускорители, а то код совсем тормозит. Хотя по мне лучше Lua развивать для замены питухония, создавать трансляторы Lua-->C++ чтобы можно было создавать максимально быстрый код.
А пока питоша делает явно не то что надо. И ещё, код получиться более громоздкий по сравнению с С++. Таки дела, простой ЯП, ну такой простой. Хахахаха

 

Ох ты мой маленький правдолюб, вскрыватель покровов и разоблачатель петухоновских заговоров. Во-первых, Петухон медленный, и это известно абсолютно всем без твоих бенчмарков, во-вторых, чтобы сделать нормальный бенчмарк, нужно уметь кодить на этом языке, для которого ты пишешь бенчмарк (все те 0.00000001 петухоновских программистов, которые твой вскрывающий покровы бенчмарк мд5 увидять, просто поржут с того, как плохо ты его сделал, и пойдут дальше свои нейронки на Петухоне обучать), в третьих, никому в целом мире не нужно на Петухоне писать мд5, тк она уже встроена в стандартную библиотеку, этож тебе не ассемблер или луа, все нужное уже есть, ну и в четвертых, рептилоиды жидомассоны, которые убедили весь мир в том, что Петухон - это хорошо, все равно не позволят придать огласке твои вскрывающие покровы бенчмарки.

 

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

 

Получилось.
File 'testMD5.txt', size = 65461
MD5: C974D84E6BADA397BEFA67FA12B36F
[1] ExeTime: 0.094 sec, Speed: 699368 bytes/sec
Хеш верный, и скорость возросла. Хотя намного меньше С++/Ассм
HoShiMin, Да, код определённо более громоздкий, не намного, но приходится усекать & 0xFFFFFFFF, что эквивалентно (u32). На JS точно так же надо делать, иначе будет не то.

 

А скинь глянуть

 

Ну может и быстрей можно сделать, но код по любому будет медленней С++/Ассм.
ЗЫ
Кстати, на ассме немного быстрей варианта С++ студия 2010, оптимизация максимальная на скорость. А питошка медленней в 500 раз, хотя надо более крупными файлами проверить.

 

надо сказать был

поглядите революцию в версиях 3.11-3.12

 

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

 

Да, попытался оптимизировать код и всё равно медленный, разница по скорости с С++ в 370 раз, это на домашнем, райзен 3600Х. Возможно джит ускорит, но вряд ли получится скорость хотя бы 1 к 10.
Смысл был дать такую задачу, где питухоний полюбому проиграет.

 

Так он в любой проиграет по скорости. Это же интерпретатор. Он никак не сможет даже приблизиться к скорости нативного кода.

--- Сообщение объединено, 17 ноя 2023 ---

Вообще, с джитом на чистой математике может получиться даже один к одному, но ты потеряешь время на компиляцию при запуске. Возможно, компиляция займёт даже больше времени, чем он выполнялся бы интерпретатором. Для скриптов это неприемлемо.
Например, в джаве для быстрого запуска программа начинает интерпретироваться и по мере прогрева уже начинает компилироваться JIT’ом. Это нормальный подход для долгоживущих программ, а скрипт не успеет запуститься, как пора завершаться: некогда собирать в машинный код.

 

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

 

А что за папка __pycache__? Это байткод конечно. В общем, небольшие скрипты могут быстро компилироваться, да и большие. Короче, можно спокойно компилить хотя бы со скоростью мегабайт кода в сек, ну или чуть поменьше, тогда это не проблема. Но как я понял в роликах на ютубе, JIT надо устанавливать отдельно.
В прочим, вся эта возня показала, что никакой особой волшебной скорости разработки на питухонии просто нет, проще сразу ковырять С++, осваивая его, изучай всякие фреймворки, и так далее.

 

едва ль нечто иное.. а вот это, пожалуй, интересней..

--- Сообщение объединено, 18 ноя 2023 ---

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

--- Сообщение объединено, 18 ноя 2023 ---

на лине он по дефолту стоит (в убунте точно).

--- Сообщение объединено, 18 ноя 2023 ---

ща я тебе скажу одно слово.. pycharm на питохе и большую крень пишут, тч джит там весьма не лишний.

 

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

--- Сообщение объединено, 18 ноя 2023 ---

Вообще, даже десктопного софта много на Петухоне. Например, видео редактор Flowblade на Петухоне написан, и многие вещи в нем тормозят меньше, чем в Kdenlive, который на Плюсах и Qt. Загадка бытия, по примитивной логике местных, должен быть минимум в 500 раз медленнее, но нет.

--- Сообщение объединено, 18 ноя 2023 ---

Внезапно, Swift оказывается добротным ЯП с интересными идеями:

 

Питухонцы всё равно проиграли. Матрицу 500х500 питоша умножал за 18.8 сек, а С++ 0.347, жаба 0.685. Потом подключил к питухонию numpy и получилось 0.228 сек.
Это быстрей чем на ассемблере, но не на оптимизированном коде, чисто на FPU, у меня 0.460 сек. Потом задействовал SSE2 и получилось 0.314 сек.
Но потом ещё раз оптимизировал и получилось 96-98 миллисек

Код (ASM):

1. ;; v0.01
2. .686
3. .xmm
4. .model flat, stdcall
5. option casemap:none
6. include \masm32\include\windows.inc
7. include \masm32\include\kernel32.inc
8. includelib \masm32\lib\kernel32.lib
9. include msvcrt.inc
10. include macros.asm
11. .code
12. main proc
13. local time:sdword, tmp:sdword, i:sdword, j:sdword
14. local A:dword, B:dword, R:dword
15.     mov     time, clock()
16.     ASSUME  esi:ptr real8, edi:ptr real8, ebx:ptr real8
17.     mov     A, GlobalAlloc(GPTR, 500*500*8)
18.     mov     B, GlobalAlloc(GPTR, 500*500*8)
19.     mov     R, GlobalAlloc(GPTR, 500*500*8)
20.     mov     esi, A
21.     mov     edi, B
22.     mov     ebx, R
23.     .for (eax=0, i=eax: i<500: i++)
24.         .for (eax=0, j=eax: j<500: j++, esi+=8, edi+=8, ebx+=8)
25.             mov     tmp, rand()
26.             fild    tmp
27.             fstp    [esi]           ;A[i][j] = (double)rand();
28.             mov     tmp, rand()
29.             fild    tmp
30.             fstp    [edi]           ;B[i][j] = (double)rand();
31.             fldz
32.             fstp    [ebx]           ;R[i][j] = 0.0;
33.         .endfor
34.     .endfor
35.     mov     ebx, R
36.     .for (eax=0: eax<500: eax++)                        ;i:eax
37.         .for (edx=0: edx<500: edx++, ebx+=sizeof real8) ;j:edx
38.             imul    esi, eax, 500*sizeof real8
39.             add     esi, A                      ;=&A[i][0];
40.             mov     edi, B
41.             lea     edi, [edi+edx*sizeof real8] ;=&B[0][j];
42.             movsd   xmm1, [ebx]                 ;sum = R[i][j]
43.             .for (ecx=0: ecx<500: ecx++)                ;k:ecx
44.                 ;sum += A[i][k] * B[k][j]
45.                 movsd   xmm0, [esi]
46.                 mulsd   xmm0, [edi]
47.                 addsd   xmm1, xmm0
48.                 add     esi, sizeof real8
49.                 add     edi, 500*sizeof real8
50.             .endfor
51.             movsd   [ebx], xmm1                 ;R[i][j] = sum
52.         .endfor
53.     .endfor
54.     neg     time
55.     add     time, clock()
56.     printf("time = %d ms\n", time)
57.     GlobalFree(A)
58.     GlobalFree(B)
59.     GlobalFree(R)
60.     ASSUME  esi:nothing, edi:nothing, ebx:nothing
61.     push    0
62.     call    ExitProcess ;;_noreturn
63. main endp
64. end main

И это конечно не придел, могу ещё ускорить.
Код на самом деле не так уж громоздкий, и кроме того я так же могу сделать свою библиотеку, запихнув этот код в макрос, и потом вызывать его одной строчкой. Так что опять питошка проиграл. Чего только к нему не придумали, а всё равно проигрывает.
ЗЫ
У меня питухоний матрицу умножил за 19.487 сек, у блогера на видео ПК чуток помощней.

 

Господа!



Что у вас за проекты на питуне, что так скорость критична,
и питоний не тянет и все время проигрывает?

Зачем вы столько матриц друг на друга умножаете?

 

да, в основном тамо жаба, но и питоха присутствует

даже разгребая строки, всё зависит от их кол-ва

--- Сообщение объединено, 19 ноя 2023 ---

Intro, теперь подключи длинную арифу

--- Сообщение объединено, 19 ноя 2023 ---

и прям ффмпег не юзает?