Исходное сообщение
"Релиз интерпретатора языка программирования Perl 5.18" Отправлено ragus, 23-Май-13 01:01
> Если вы не умеете пользоваться всей мощью регексов это не значит, что > этого не умеют другие. А регексы re2 весьма сильно ограничены и > код переписывать под них придется. Ну или воспользоваться модулем, который умеет > fallback в стандартные регексы еще раз: 1)вы переоцениваете важность регекспов. 2)пример выше про легкость замены, а не о совместимости. т.е. там, где это допустимо. более того, можно использовать одновременно оба движка, в том числе разнеся их по разным cpu. > Нравится по граблям топтаться? pack/unpack встроенны в perl и конечно же имеют > больше возможностей чем питоновские из struct о, можно подробнее про грабли? и чего нет в питоновском struct? >> 3. можно еще распараллелиться > Или поставить более мощный процессор, или дать больше памяти, или увеличить пропускную > способность IO. Это экстенсивный путь, мы не о нем. если у вас в системе 32cpu и они ничем не загружены - почему бы и нет? >> 4. в случае с python есть cython(да, для нормального ускорения нужна статическая >> типизация). > Это конечно тоже имеет право на жизнь, но как по мне, ускорять > надо не программу в целом, жертвуя возможностями языка, а проблемный кусок > кода. ну так о куске кода и речь. профайлером нашли горячий кусок, вынесли в модуль, а дальше cython. тем более, что cython с ключём '-a' сгенерирует красивый отчёт и подскажет, что надо типизировать в первую очередь. > И ситуация, когда работоспособность кода на ЯП зависит от используемого > транслятора, мне не кажется верным подходом. Кстати для perl давным давно > была возможность превращать весь код в C, но она толком никому > не была нужна и ее забросили, зато создали несколько различных способов > подключать C код. ну так cython так и умеет. только ускорение от прямой трансляции невелико, потому и забросили в perl. >> 5. в случае с python есть pypy и его jit. тут переписывать >> вообще не надо. > Если там так все хорошо, то почему pypy болтается на задворках, а > не вытеснил другие реализации? откуда ж мне знать? народ весьма консервативен. ~/bench$ python levbench.py st1 == 7800 bytes, st2 == 8580 bytes 27.2362930775 ~/bench$ pypy levbench.py st1 == 7800 bytes, st2 == 8580 bytes 2.71952915192 один и тот же код, взятый тут: http://en.wikibooks.org/wiki/Algorithm_Implementation/String...

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Если вы не умеете пользоваться всей мощью регексов это не значит, что >> этого не умеют другие. А регексы re2 весьма сильно ограничены и >> код переписывать под них придется. Ну или воспользоваться модулем, который умеет >> fallback в стандартные регексы > еще раз: > 1)вы переоцениваете важность регекспов. > 2)пример выше про легкость замены, а не о совместимости. т.е. там, где > это допустимо. > более того, можно использовать одновременно оба движка, в том числе разнеся их > по разным cpu. >> Нравится по граблям топтаться? pack/unpack встроенны в perl и конечно же имеют >> больше возможностей чем питоновские из struct > о, можно подробнее про грабли? и чего нет в питоновском struct? >>> 3. можно еще распараллелиться >> Или поставить более мощный процессор, или дать больше памяти, или увеличить пропускную >> способность IO. Это экстенсивный путь, мы не о нем. > если у вас в системе 32cpu и они ничем не загружены - > почему бы и нет? >>> 4. в случае с python есть cython(да, для нормального ускорения нужна статическая >>> типизация). >> Это конечно тоже имеет право на жизнь, но как по мне, ускорять >> надо не программу в целом, жертвуя возможностями языка, а проблемный кусок >> кода. > ну так о куске кода и речь. профайлером нашли горячий кусок, вынесли > в модуль, а дальше cython. тем более, что cython с ключём > '-a' сгенерирует красивый отчёт и подскажет, что надо типизировать в первую > очередь. >> И ситуация, когда работоспособность кода на ЯП зависит от используемого >> транслятора, мне не кажется верным подходом. Кстати для perl давным давно >> была возможность превращать весь код в C, но она толком никому >> не была нужна и ее забросили, зато создали несколько различных способов >> подключать C код. > ну так cython так и умеет. только ускорение от прямой трансляции невелико, > потому и забросили в perl. >>> 5. в случае с python есть pypy и его jit. тут переписывать >>> вообще не надо. >> Если там так все хорошо, то почему pypy болтается на задворках, а >> не вытеснил другие реализации? > откуда ж мне знать? народ весьма консервативен. > [CODE] > ~/bench$ python levbench.py > st1 == 7800 bytes, st2 == 8580 bytes > 27.2362930775 > ~/bench$ pypy levbench.py > st1 == 7800 bytes, st2 == 8580 bytes > 2.71952915192 > [/CODE] > один и тот же код, взятый тут: > http://en.wikibooks.org/wiki/Algorithm_Implementation/Strings/Levenshtein_distance
	Введите код, изображенный на картинке: