Что быстрее, Bash или Python?

Питон забавный. Всё никак в толк не мог взять - как бэкендщики умудряются вызвать функции PG без приведения к типу входных параметров. И даже не интересуются какие типы на входе у функции. PG же не умеет сам приводить int2 к int4, естественно, пока явно не попросишь.

Вчера взял в руки Python и его psycopg2 - и знаете что? Оказывается он когда видит строку типа '1' САМ приводит её к 1::int2 (наименьшему подходящему типу целого). По-моему очень смешно - перетаскивать int2 в строку, чтобы потом из строки обратно в int2 Питон сам перевел. Второй день под впечатлением, никак не отпускает.

Сказки народные читать надо

Для этого есть ЛОР. Тут порой такие отборные сказочники из народа…

А потом её обжимка с помощью отвёртки. Плавали, знаем. :)

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

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

java

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

Тоже мне вопрос, серьезные люди сравнивают баш на локалхосте со всякими кластерами

https://adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html

time perl python-world.py

Неплохо-неплохо :) Perl умеет запускать скрипты на python, да ещё и гораздо быстрее :)

Ну print и там и там есть, да и скрипт простейший. Хотя если приглядеться Perl не добавил «\n» в конце строки. А так конечно для чуть более сложно скрипта - это фантастика.

Обжим отверткой/ножницами/etc это банальщина, все это проходили :) Но вот обрезание витухи молотком я в своей жизни видел один раз. Это была просто «истерия» от «начальника» которому не понравились длинные концы, он взял молоток, отфигачил кусок и сказал «вот теперь переобжимайте» :) Это в сервачной было которую мы переоборудовали в выходные.

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

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

Что быстрее, молоток или плоскогубцы?

Два чая этому господину.

Эти вещи немного разные.

Баш написан на си => баш быстрее.

:D

Прочтение темы вызывает острое желание начать писать скриптуху на c++ :) Ибо нефиг.

Я уже начал... cgi-скрипт на C++
OpenKlest Light Edition 2.0.0
😄😄😄

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

может конкурс запилить?

Я заочно победил. У меня C++-скрипт использует AJAX. Более извращённое можете придумать?

Да!

Единственный адекват в треде.

Время реакции не имеет ничего общего с механизмом вычисления.

Это если ты не думаешь, а если думаешь, то это верный способ задержать сложное действие.

Если ты в свой выключатель света встроишь RPI, которая будет отлавливать нажатие выключателя через GPIO, а потом по сети по HTTP-протоколу будет посылать GET-запрос на сервер,

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

Как и все остальное что ты написал - не имеют ничего общего со «скоростью».

Нет, это ты в отрицалово ушел, т.к. тебе обидно что твоя думалка медленная.

Хочешь измерить скорость ? Запросто. Пиши на своем opencv алгоритм определения отличия леопарда от леопардового дивана и замеряй скорость определения им, а потом ребенком лет этак 10-ти. УДИВИШЬСЯ. Так и быть, в качестве форы разрешаю использовать камеру 120fps

Передача компактдисков камазами быстрее, если не считать затраты на запись компактдисков и загрузку камазов :) Это все равно не отменяет что ты имеешь задержки и узкие места. В случае человеко-комплюктерной системы тормозит человек.

Ты наверное веришь что афоризмы что-то там отражают в действительности. А если их начать разбирать — они либо из контекста вырваны, где смысл совсем другой, либо фактически поэтическое вранье. «Быстромысль» из сказки казалась быстрой авторам, пока не разобрались насколько она действительно быстра. Не так уж чтоб очень и быстра оказалась.

С коллегой тут закусился что быстрее работает?

Их некорректно сравнивать по скорости, потому что CPU-bound код на них самих вообще не пишут - bash склеивает утилиты, а python - модули, в обоих случаях написанные на более производительных языках, а собственная производительность языков, будь там хоть 100x в любую сторону, никого вообще не волнует.

Это зависит от задачи. Обычно bash напропалую использует ультраоптимизированные unix tools и если задача кладётся на их использование, то скорость обработки близка к ассемблеру. Питон в свою очередь тоже имеет биндинги к ультраоптимизированным библиотекам вроде numpy, которые молотят данные вместо питона. Проблемы с параллельным выполнением решаемы и там и там. Так что без обсуждения типа задачи нельзя сказать что быстрее.

Можно считать интеграл на машине

Машина как правило не делает ничего, что в принципе нельзя делать на бумажке, только долго :)

Если интеграл берется то на бумажке быстрее.

А если табличка уже есть из прошлых вычислений, ничего не надо решать, но это всего лишь кэширование :) Точно так же твои «готовые знания» быстрее чем сознательные мысленные усилия по пониманию почему то что ты знаешь верно.

Всётаки ты компьютерщик. Но ты же не думаешь что в контексте сказки кто-то думал про скорость нервных процессов?

«Быстромысль» быстра потому, что ты сразу за стольным градом думаешь про заморскую страну. И к скорости процессов в ЦНС это не имеет никакого отношения. Как скорость света не имеет отношения к скорости солнечного зайчика. И эта логика в таком виде из глубины времён принесена сказкой.

А то, что в твоём контексте это не имеет смысла – это другой вопрос. Как другой вопрос и то, что афоризмы отражают что то так же, как любой продукт деятельности ЦНС. И то, что именно и каким образом это они там отражают.

Эт смотря как кидать.

Тю. Слабак. Учись. :)

Java близко не стоит к скриптовым языкам. Тогда уж JavaScript, который действительно быстрее чем Python и bash, если брать его реализацию в node.js.

Тю. Слабак. Учись. :)

А описание? Это web-сервер на bash? Так не бывает. :D

Это MVC движок на баше с хранением данных в mysql. :) Работает через CGI. CMS по-нашему.

Че он тогда такой медленный?

Смотря с чем сравнивать. Я медлительности не замечал.

Java близко не стоит к скриптовым языкам. Тогда уж JavaScript, который действительно быстрее чем Python и bash, если брать его реализацию в node.js.

Если говорить про скриптовые языки, то да, Вы правы, уместней было бы вспомнить Lua.

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

Только позиционирование самого языка? Но ведь и Python, насколько я знаю, в последнее время позиционируется не как скриптовой язык, а как ЯП общего назначения. Есть упоминания, что даже значительная чась Ютубчика реализована на Питоне.

Исполнение в контексте некоей виртуальной среды? Но и Java и C# тоже выполняются в виртуальных машинах. Формально даже конструкции сишечки имеют смысл только в контексте виртуальной С-машины. И только во время компиляции семантике инструкций этой машины сопоставляется байт-код реальной машины.

Отсутствие компилятора, и исполнение команд языка интерпретатором? Тут уже становится совсем непонятно. JIT-компилятор это уже полноценный компилятор, или все ещё продвинутая форма интерпретатора? А если используется сразу несколько подходов? Та же jvm не всегда задействует JIT - по усмотрению java-машины java-байт-код может выполнятся и в режиме интерпретации.

Наконец, даже байт-код реальных архитектур, является лишь публичным интерфейсом процессоров, и по факту не исполняется команда за командой (что кстати можно было бы расценить как исполнение интерпретатором), а перед выполнением преобразуется в команды конкретной микроархитектуры (фактически встроенный в процессоры JIT).

оба языка могут создать файл непосредственно исполняемый на целевой машине следовательно вопрос сводится насколько быстро bash али python может спродуцировать машкод целевой программы на целевой машине

собственно в ч>м вопрос то?

собственно в ч>м вопрос то?

Как очень точно отметили выше, вопрос сводится к следующему:

Что быстрее, молоток или плоскогубцы?

питухон, так как начитался недавних пресс-релизовоб ускорении аж до 60%

Предположу что он и без ускорений работал быстрее. Вряд ли писатели баша вообще заморачивались про скорость.

Я медлительности не замечал

Так ты ж ничего слаще морковки не пробовал. Питон вообще самый медленный из общеиспользуемой скриптоты. В топе нода и пых.

Это с чего выводы, что не пробовал. Как раз таки писал на пыхе, а также на JS. И даже на C++ писал и продолжаю писать. И на go и на rust (в качестве хобби).

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

Это с чего выводы

Ты ж сам сказал в прошлый раз.

Как раз таки писал на пыхе, а также на JS

ЛОЛ, т.е. выводы о том что на пыхе сплошь говнокод ты сделал по результатам своего писательства? Ясно-понятно.

Поэтому как раз могу сравнивать, и не только по быстродействию

Очевидно же, что не можешь. Какие-то проблемы с критическим мышлением. Тебе дают пруф, что питон сосёт по скорости, но ты продолжаешь утверждать что «вы всё врёти».

Тебе дают пруф, что питон сосёт по скорости, но ты продолжаешь утверждать что «вы всё врёти».

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

не утверждал, ни что Python - самый быстрый язык, ни что все врут

А, да? Тогда

Смотря с чем сравнивать. Я медлительности не замечал

С чем же ты сравнивал? Или просто так ляпнул?

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

def parser():
    order = []
    names = []
    cmd = []
    ip_list = []
    port_list = []
    port_avail = []
    global united_dict
    with open('aliases', 'r') as f:
        test = f.readlines()
        i = 0
        for line in test:
            order.append(i)
            names.append(finder(pattern_name, line))
            cmd.append(finder(pattern_command, line))
            ip_list.append(finder(pattern_ip, line))
            port_list.append(finder(pattern_port, line))
            port_avail.append(port_test(finder(pattern_ip, line), finder(pattern_port, line)))
            i = i + 1
    f.close()
    united_dict = {z[0]: list(z[1:]) for z in zip(order, names, cmd, ip_list, port_list, port_avail)}
    names.clear()
    cmd.clear()
    ip_list.clear()
    port_list.clear()
    order.clear()

Пихнуть списки в одну структуру, и разделить подзадачи на методы этой структуры.

Зачем в конце очищать? Сборщик мусора очистит.

Вместо global united_dict надо возвращать построенный словарь, иначе это очень плохой паттерн.

И ещё: можно сразу итерироваться по файлу:

for line in open('aliases'):
  print(line)

«Готовые знания» с т.з. науки вообще малоинтересны, интересны новые знания. И вот с т.з. производства новых знаний оптимальным является симбиоз компутера и человеческих мозгов. Но человеческие мозги способны давать прирост в производительности куда больше, чем смена яп.

lol веет питоном 1.5.2?

ща оно какбе похоже на тОкое:

finder=port_test=pattern_name=pattern_command=pattern_ip=pattern_port=lambda *x:None
def parser():
    wow=((i,
        finder(pattern_name, line),
        finder(pattern_command, line),
        finder(pattern_ip, line),
        finder(pattern_port, line),
        port_test(finder(pattern_ip, line), finder(pattern_port, line)),
    ) for i,line in enumerate(open('aliases', 'r').readlines()))
    global united_dict
    united_dict = {z[0]: list(z[1:]) for z in zip(*wow)}
    None
 

эээ

finder=port_test=pattern_name=pattern_command=pattern_ip=pattern_port=lambda *x:None
def parser(fn):
    wow=(finder(pattern_name, line),
        finder(pattern_command, line),
        finder(pattern_ip, line),
        finder(pattern_port, line),
        port_test(finder(pattern_ip, line), finder(pattern_port, line)),
    ) for line in open(fn, 'r').readlines()))
    return {i:z for i,z in enumerate(zip(*wow))}
   
united_dict=parser('aliases')

egcz:

finder=port_test=pattern_name=pattern_command=pattern_ip=pattern_port=lambda *x:None
finderW=lambda o,p:finder(p,o)
united_list=[(
        finderW(L,pattern_name),
        finderW(L,pattern_command),
        x:=finderW(L,pattern_ip),
        y:=finderW(L,pattern_port),
        port_test(x, y),
    ) for L in open('aliases')]

Вряд ли эта волшебная лапша чем-то лучше квадратно-гнездового исходника.

ващет если убрать осписоченье то так то итератор ленывый