Что быстрее, Bash или Python?
ПРивет, посоны. С коллегой тут закусился, что быстрее работает? Я топил за питон, так как начитался недавних пресс-релизов об ускорении аж до 60%. Но других аргументов то у меня собственно и нет. Поэтому пришёл сюда, чтобы набраться мудрости и завтра ковровым аргументометанием принудить его к миру.
Зависит от задачи. Если вызывать сторонние программы в основном, то Bash может быть быстрее за счёт меньшего времени непосредственно запуска скрипта (в самом начале). В большинстве остальных задач Python будет быстрее, и надо уже сравнивать насколько.
да это то понятно. Я тут, кстати, перед завтраком ядро на нём переписал
Ну замеряйте. Прогоните пару задач.
Что быстрее, молоток или плоскогубцы?
Молоток. У плоскогубцев аэродинамика слабовата
А если нужно не забивать гвоздь, а проволоку согнуть особым манером?
Прочтение темы вызывает острое желание начать писать скриптуху на c++ 🙂 Ибо нефиг.
hobbit ★★★★★ ( 21.11.22 08:39:45 MSK )
Последнее исправление: hobbit 21.11.22 08:40:04 MSK (всего исправлений: 1)
Баш – это клей для очень быстрых программ на Си. В зависимости от задачи он может быть как ОЧЕНЬ быстрее, так и очень медленнее.
А если нужно не забивать гвоздь, а проволоку согнуть особым манером?
Если сгибать под прямым углом, пара ударов молотком быстрее, чем возиться с плоскогубцами. Но в этом случае молоток требует большего мастерства. Про КРУГЛОгубцы речь не шла 🙂
Баш хоть вызывается моментально, питон пока запустится можно чай заварить.
А если в баш-скрипте запустить питон, то можно заварить чай, пока запускается баш? 🙂
Ты просто не умеешь пользоваться плоскогубцами. Ну или я молотком. 🙂
Быстрее всего мысль человеческая. Хороший алгоритм на баше/питоне быстрее плозого алгоритма на плюсах.
Шуруп забитый молотком держит лучше чем гвоздь закрученный отверткой. А молотковая резьба вообще самое прочное соединение.
Баш написан на си => баш быстрее.
За 0.185 сек. ты вряд ли заваришь чай, но вот проглотить таблетку теоретически успеешь.
Ну как бы. Числа складывать питон явно быстрее будет. Инициализироваться и вызывать другие программы баш. Какие ваши бенчмарки?
[cppmm@damned compare]$ time ./c-world Hello, World! real 0m1,002s user 0m0,002s sys 0m0,000s [cppmm@damned compare]$ time ./python-world.py Hello, World! real 0m0,051s user 0m0,047s sys 0m0,003s 
Я как-то делал инвентаризацию сети (состоящей на 99,9% из Cisco).
Программа должна была лазать по железкам по SNMP, собирать инфу и
рекурсивно обходить сегмент сети на основании таблички CDP.
Так вот, прототип я наваял на bash+snmpwalk/snmpget и так далее.
Работало это миллион лет. Но концепт зашёл и я переписал на C+netsnmp.
Уверен что на питоне работало бы так же быстро, как и на С.
[cppmm@damned compare]$ python --version Python 3.10.8 Но я бы искал причину такого поведения не в версии питона, а в исходниках тестов. 😉
В Python 3.11 — ускорили инициализацию, быстрее должен быть запуск.
Если и проявляется, то на чём-то более тяжёлом.
[cppmm@damned compare]$ python --version Python 3.10.8 [cppmm@damned compare]$ time ./python-world.py Hello, World! real 0m0,047s user 0m0,046s sys 0m0,000s [cppmm@damned compare]$ sudo eselect python set 2 [cppmm@damned compare]$ python --version Python 3.11.0 [cppmm@damned compare]$ time ./python-world.py Hello, World! real 0m0,044s user 0m0,033s sys 0m0,010s [cppmm@damned compare]$ 
Правильно топил. Но дело тут не в скорости, а в том что bash — это не ЯП, а шелл, его задача — комбинировать запуск\вывод\ввод внешних программ, что априори не может быть быстрее.
#!/bin/bash let a=1 if [[ $a == 1 ]];then echo "hello world"; fi Сколько внешних программ вызывает баш при обработке этого кода ?)
Скобочки надо было в if одинарные использовать, тогда в вопросе был бы подвох.
Баш написан на си => баш быстрее.
Удивительно, но Python тоже написан на C. Поэтому, скорости равны!
bash ЕМНИП даже в байт-код не умеет компилироваться, не то что там jit. Так что на каком-нибудь перебирании массивов слив будет на порядок https://unix.stackexchange.com/questions/303157/is-there-something-wrong-with-my-script-or-is-bash-much-slower-than-python
Но спор абсолютно бессмысленный, разве что набросить на лоре, для задач, где применяют пистон баш не применяют, и наоборот.
goingUp ★★★★★ ( 21.11.22 12:25:56 MSK )
Последнее исправление: goingUp 21.11.22 12:27:28 MSK (всего исправлений: 1)
«Мысль человеческая» довольно тормозная т.к. распространение сигнала по нервам медленнее чем в проводниках. Даже в ПДД прописана задержка на типичное время реакции для действия в котором головной моск почти не участвует. За одну секунду медленный старый комплюктер сделает дофига вычислений. А человеку если активно подумать надо при высокой неопределенности (ситуация совсем новая, т.е. требует логических выводов или обучения) — тут вообще идеал «овернайт», т.е. «переспать с проблемой». Итого, пользователь самая медленная часть системы.
Конечно баш быстрее. Пока питонисты подсчитают все отступы, баш уже всё сделает.
Скорость распространения сигнала по нервам не имеет значения, поскольку вычисления недискретны.
Вряд ли она вообще применима к организмам.
Имеет, потому что организмы медленнее компьютеров, независимо от механизма вычислений. гугл «Время реакции». Алсо сознание человеков медленне их подкорковых процессов и спинного моска, а подкорковые процессы не умеют в смену стратегии поведения, кроме выбора из уже известных (заученных до автоматизма), которые стратегии никогда на ходу не разрабатываются (должен сформироваться навык или сконсолидироваться память), это тупо экспериментально проверенные эмпиричеакие факты.
Так-то Perl всё-равно делает Python как стоячего.
$ time perl python-world.py Hello, World! ________________________________________________________ Executed in 5.46 millis fish external usr time 2.96 millis 0.00 micros 2.96 millis sys time 2.52 millis 563.00 micros 1.96 millis $ time python3 python-world.py Hello, World! ________________________________________________________ Executed in 69.81 millis fish external usr time 57.88 millis 345.00 micros 57.54 millis sys time 11.15 millis 246.00 micros 10.91 millis
Время реакции не имеет ничего общего с механизмом вычисления.
Если ты в свой выключатель света встроишь RPI, которая будет отлавливать нажатие выключателя через GPIO, а потом по сети по HTTP-протоколу будет посылать GET-запрос на сервер, который его обработает баш-скриптом if\then и пошлет в свою очередь запрос на RPI люстры, которая через реле зажжет лампочку — время реакции тоже будет медленное, но это не значит что а) Сервер тормознутый; б) Прямая цепочка «выключатель-лампочка» будет вычислять быстрее сервера.
Как и все остальное что ты написал — не имеют ничего общего со «скоростью».
Хочешь измерить скорость ? Запросто. Пиши на своем opencv алгоритм определения отличия леопарда от леопардового дивана и замеряй скорость определения им, а потом ребенком лет этак 10-ти. УДИВИШЬСЯ. Так и быть, в качестве форы разрешаю использовать камеру 120fps.
Ты наверно компьютерщик какой-то, не понимаешь русского языка.
«Быстрее всего мысль человеческая» означает совсем не то, что ты понимаешь по компьютерски. Это означает что вот ты думаешь о том что перед тобой и вот подумал о Москве а затем сразу о заморском берегу. И это и означает что мысль быстрее чем ты добежишь туда пешком или долетишь на своей новомодной воздушной повозке. Сказки народные читать надо, а не только свои «маны».
Python vs Bash — In which kind of tasks each one outruns the other performance-wise? [closed]
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Obviously Python is more user friendly, a quick search on google shows many results that say that, as Python is byte-compiled is usually faster. I even found this that claims that you can see an improvement of over 2000% on dictionary-based operations. What is your experience on this matter? In which kind of task each one is a clear winner?
Python is drastically faster on text processing, which is a common operation. If I perform the same search 10000 times on each language, on Bash it takes 1m24s, on Python 636ms. This is because Bash use a sub-process for each operation of the text processing, which is slow to create.
11 Answers 11
Typical mainframe flow.
Input Disk/Tape/User (runtime) --> Job Control Language (JCL) --> Output Disk/Tape/Screen/Printer | ^ v | `--> COBOL Program --------' Typical Linux flow.
Input Disk/SSD/User (runtime) --> sh/bash/ksh/zsh/. ----------> Output Disk/SSD/Screen/Printer | ^ v | `--> Python script --------' | ^ v | `--> awk script -----------' | ^ v | `--> sed script -----------' | ^ v | `--> C/C++ program --------' | ^ v | `--- Java program ---------' | ^ v | : : Shells are the glue of Linux
Linux shells like sh/ksh/bash/. provide input/output/flow-control designation facilities much like the old mainframe Job Control Language. but on steroids! They are Turing complete languages in their own right while being optimized to efficiently pass data and control to and from other executing processes written in any language the O/S supports.
Most Linux applications, regardless what language the bulk of the program is written in, depend on shell scripts and Bash has become the most common. Clicking an icon on the desktop usually runs a short Bash script. That script, either directly or indirectly, knows where all the files needed are and sets variables and command line parameters, finally calling the program. That’s a shell’s simplest use.
Linux as we know it however would hardly be Linux without the thousands of shell scripts that startup the system, respond to events, control execution priorities and compile, configure and run programs. Many of these are quite large and complex.
Shells provide an infrastructure that lets us use pre-built components that are linked together at run time rather than compile time. Those components are free-standing programs in their own right that can be used alone or in other combinations without recompiling. The syntax for calling them is indistinguishable from that of a Bash builtin command, and there are in fact numerous builtin commands for which there is also a stand-alone executable on the system, often having additional options.
There is no language-wide difference between Python and Bash in performance. It entirely depends on how each is coded and which external tools are called.
Any of the well known tools like awk, sed, grep, bc, dc, tr, etc. will leave doing those operations in either language in the dust. Bash then is preferred for anything without a graphical user interface since it is easier and more efficient to call and pass data back from a tool like those with Bash than Python.
Performance
It depends on which programs the Bash shell script calls and their suitability for the subtask they are given whether the overall throughput and/or responsiveness will be better or worse than the equivalent Python. To complicate matters Python, like most languages, can also call other executables, though it is more cumbersome and thus not as often used.
User Interface
One area where Python is the clear winner is user interface. That makes it an excellent language for building local or client-server applications as it natively supports GTK graphics and is far more intuitive than Bash.
Bash only understands text. Other tools must be called for a GUI and data passed back from them. A Python script is one option. Faster but less flexible options are the binaries like YAD, Zenity, and GTKDialog.
While shells like Bash work well with GUIs like Yad, GtkDialog (embedded XML-like interface to GTK+ functions), dialog, and xmessage, Python is much more capable and so better for complex GUI windows.
Summary
Building with shell scripts is like assembling a computer with off-the-shelf components the way desktop PCs are.
Building with Python, C++ or most any other language is more like building a computer by soldering the chips (libraries) and other electronic parts together the way smartphones are.
The best results are usually obtained by using a combination of languages where each can do what they do best. One developer calls this «polyglot programming».