Обзор новых возможностей в Python 2.6 и 3.0

P.S. AMD Processor model unknown 1400 MHz

сравнивал при 100000. java -server дала 51.6 секунд, python дал 54.3 секунды. Таким образом производительность одинаковая в пределах погрешности, при этом пайтон, как я понимаю, вызывает сишные либы, java использует всё на java. Поэтому я позволю себе усомниться в первоначальном посте, что java тормозит из за этого.

>в рхеле все утили написаны на питоне

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

> У тебя неправильный C. У меня миллион за 8 секунд отрабатывает.

Значит процессор шустрее. У меня ноутбучный пентиум какой то. 1.73 GHz

Поставил 1000000. В цикле 6997 мс, если вынести - 2607.

> Если не измениться - ложь.

java бесплатная, скачивайте, проверяйте.

>при этом пайтон, как я понимаю, вызывает сишные либы

На правда! Регулярные приложения в Python написаны на чистом Python, без всяких C. См. /usr/lib/python2.5/re.py, /usr/lib/python2.5/sre*.py

> я позволю себе усомниться в первоначальном посте, что java тормозит из за этого.

А я позволю себе усомниться в посте, утверждавшем, что Питон тормознее Явы :)

Гм, ну тогда не понятно, что сравнивали.

Ладно, а никто не подскажет как скомпилит с pcreposix.h?
gcc говорит:
/tmp/cceUZ839.o: In function `main':
regex.c:(.text+0x7f): undefined reference to `pcreposix_regcomp'
regex.c:(.text+0xd4): undefined reference to `pcreposix_regexec'
regex.c:(.text+0x12f): undefined reference to `pcreposix_regfree'
collect2: выполнение ld завершилось с кодом возврата 1

Что за? Код тот же, просто мне нужные именно pcre:

#include <stdio.h>
#include <pcreposix.h>
#include <string.h>

int main(){
	char subject[] = "Re[42]: some subject this";

	int num;
	char num_str[5]="";
	regex_t re;
	regmatch_t rm[2];

	if( regcomp(&re, "^Re\\[([0-9]{0,5})\\]:", REG_EXTENDED|REG_ICASE) )
	{
		printf("ERROR\n");
		return 1;
	}

	int i,l=0;
	for(i = 0; i < 1000000; i++)
	{


		if( !regexec(&re, subject, 2, rm, 0) )
		{
			strncpy(num_str, &subject[rm[1].rm_so], rm[1].rm_eo - rm[1].rm_so);
			num = atoi(num_str);
			l += num;
		}
	}

	regfree(&re);

	printf("\nTotal:%d\n", l);
	return 0;
}

Помогите, а иначе PHP обгоняет Си ;-(

> А я позволю себе усомниться в посте, утверждавшем, что Питон тормознее Явы :)

Ну давай тогда сравнивать что-нибудь, не использующее неизвестных алгоритмов. Мне это действительно интересно. Может QuickSort, запущенный n раз на m массивах?

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

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

Ничего не поделаешь, PHP это глобально и надёжно (с) :D

> Время кодеманки проходит, наступают времена умных программистов.

Прогресс необратим, будут кодеманки и на питоне.

> На правда! Регулярные приложения в Python написаны на чистом Python, без всяких C.

Обижен на Гвидо.

> Прогресс необратим, будут кодеманки и на питоне.

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

> Регулярные приложения в Python написаны на чистом Python, без всяких C. См. /usr/lib/python2.5/re.py, /usr/lib/python2.5/sre*.py

Не скажу насчет 2.5, но где в 2.4 находится модуль _sre, который импортируется в sre_compile.py? :)

> Может QuickSort, запущенный n раз на m массивах?

Здесь Питон сольет, это ясно. Такие тесты как раз входят в shootout. Мне было интересно именно обращение к "платформенным" вещам. Сегодняшний Питон - это "клей", делегирующий вычислительно емкую работу Си-библиотекам. На нем можно писать сложную логику и приложения, но где-то "под капотом" всё равно будет небольшой Си-модуль (или несколько), который решает проблему "узкого места" (Mercurial - классический пример).

Ну в таком качестве, конечно, пайтон не тормознее явы :) Это и правильно.

> Ну в таком качестве, конечно, пайтон не тормознее явы :) Это и правильно.

Ну а лучше не станет, пока PyPy с его ништяками не доведут до ума.

Вообще моё имхо, по теме тормозящей джавы - это куча зачастую лишних абстракций, и в некоторых случаях, идиотская реализация в JDK (хотя не всегда). Все эти IDE и прочее позволяют слишком вольготно обращаться с абстракциями, ну подумаешь, будет тут на 1% медленнее, там на 3%, там на 5%. А в итоге оно всё и тормозит. Собственно положительный вывод в том, что проблема в людях а не в технологии.

>Собственно положительный вывод в том, что проблема в людях а не в технологии.

+1 Только, к сожалению, быдломанагеры пытаются компенсировать криворукость своих разработчиков модными языками да технологиями.

Какая же гадость эта ваша быдложаба!

%;*№:*! Вот так рушатся мечты и иллюзии. Действительно регулярные выражения в питоне реализованы на C.

http://svn.python.org/view/python/tags/r252/Modules/_sre.c?rev=60915&view...

Фигасе.

gcc -O3 -lpcreposix r_pcre.c -o r_pcre
gcc -O3 r_posix.c -o r_posix

time ./r_posix; time ./r_pcre

Total:42000000

real	0m7.238s
user	0m5.640s
sys	0m0.028s

Total:42000000

real	0m1.004s
user	0m0.516s
sys	0m0.004s

time php regex.php

Total:42000000

real	0m6.485s
user	0m5.448s
sys	0m0.044s


Код Си:

#include <stdio.h>
#include <pcreposix.h> // OR regex.h for POSIX
#include <string.h>

int main(){
	char subject[] = "Re[42]: some subject this";

	int num;
	char num_str[5]="";
	regex_t re;
	regmatch_t rm[2];

	if( regcomp(&re, "^Re\\[([0-9]{0,5})\\]:", REG_EXTENDED|REG_ICASE) )
	{
		printf("ERROR\n");
		return 1;
	}

	int i,l=0;
	for(i = 0; i < 1000000; i++)
	{
		if( !regexec(&re, subject, 2, rm, 0) )
		{
			strncpy(num_str, &subject[rm[1].rm_so], rm[1].rm_eo - rm[1].rm_so);
			num = atoi(num_str);
			l += num;
		}
	}

	regfree(&re);

	printf("\nTotal:%d\n", l);
	return 0;
}

Код PHP:

<?php
$subject = "Re[42]: some subject this";
$l = 0;
for($i=0; $i < 1000000; $i++) {
	preg_match("/^Re\[([0-9]{0,5})\]:/", $subject, $rm);
	$l = $l + $rm[1];
}

echo "\nTotal:$l\n";


Итог: PHP проиграл. Но не понятна ситуация с компиляцией регулярок
в PHP. Но если в Си сделать перекомпиляцию - время будет 3.377s.
Т.е. все равно проиграет, но с меньшим разрывом.
PCRE в разы быстрее POSIX, использовать последний нет смысла,
особенно с наличием pcreposix.

Извините за PHP.

> PCRE в разы быстрее POSIX

s/PCRE/Релизация regexp в PCRE/

s/POSIX/реализации regexp в glibc/

> Это работает 828 миллисекунд. Ну что, джава опять обогнала С в 20 раз гыгы :)

Во-первых, один миллион в цикле:

$java -classpath . test
Total: 42000000
Total time: 3715 ms

Напомню, что код Си это сделал за 3.377s. PHP за семь.
Мда, пока Java на ровне Си.

Доколе терпеть Linux на Си??

> Доколе терпеть Linux на Си??

Точно. И ядро на Java

# cat /boot/grub/grub.conf title JLinux root (hd0,0) jvm /boot/jvm-7.1.3 kernel=/boot/jkernel-3.2.14 kernelroot=/dev/sda2

В смысле > Доколе терпеть Linux на Си??

Точно. И ядро на Java

# cat /boot/grub/grub.conf

title JLinux

root (hd0,0)

jvm /boot/jvm-7.1.3 kernel=/boot/jkernel-3.2.14 kernelroot=/dev/sda2

> На питоне очень сложно писать тупой и убогий код.

Настоящий физик напишет на Fortran'е на любом языке. (C)

Тем более, что python (IMHO) -- так себе, кривенькая новомодная поделка.

какой же ты все-таки идиот, ага, сам то сколько языков написал или хотябы _на_ языках?...

> Не скажу насчет 2.5, но где в 2.4 находится модуль _sre, который импортируется в sre_compile.py? :)

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

Питон немного не для этого. А то для чего он, на том он отлично работает. Видел и писал на нем кучу Ынтерпрайза.. живет он там отлично :-) Совместимость на очень высоком уровне: переводил большой ынтерпрайз с 1.5->2.2->2.4->2.5 с большим количеством экстеншенов и немеряным количеством прикладнухи на питоне. Гемора особого небыло.

> Тем более, что python (IMHO) -- так себе, кривенькая новомодная поделка.

Сходи на вики, глянь, сколько ему лет, прежде чем писать такую глупость

>прикинь сколько нужно будет перетаскивать на python 3 всего, у кого, скажем, был портал иль еще что-то, что использовало свой фреймвок.

Писать свои фреймворки и CMS - удел ПХП разработчиков. Для питона есть великолепные фреймворки (Django, Pylons, Turbogears), которых хватает для всего круга задач.

-module(r_pcre).

-export([main/0]).

-define(STEPS, 1000000).
-define(SUBJECT, "Re[42]: some subject this").

for(I, RE, L) ->
	if
		I =:= ?STEPS ->
			L;
		true ->
			for(I+1, RE,
				case re:run(?SUBJECT, RE, [{capture, [1], list}]) of
					{match, [S]} ->
						{N, _} = string:to_integer(S),
						L + N;
					_ ->
						L
				end
			)
	end.

main() ->
	case re:compile("^Re\\[([0-9]{0,5})\\]:", [extended, caseless]) of
		{ok, RE} ->
			L = for(0, RE, 0),
			io:fwrite("~nTotal:~p~n", [L]),
			halt();
		{error, _} ->
			io:fwrite("ERROR~n"),
			halt(1)
	end.

Запускать:

time erl -noshell -s r_pcre main

почитал оригинал и так и не понял, за чтов удалили следующие функции - apply(), callable(), coerce(), execfile(), file(), reduce(), reload().

может кто объяснит или покажет где это отбуждалось?

> Тем более, что python (IMHO) -- так себе, кривенькая новомодная поделка.

"Java is a programming language originally developed by Sun Microsystems and released in 1995 as a core component of Sun Microsystems' Java platform."

"Python was first released by Guido van Rossum in 1991." (http://svn.python.org/view/*checkout*/python/trunk/Misc/HISTORY)

>в них должен быть смысл. а не эмоции.

кто бы говорил. Вашим первым словом в известном нам топике было "идиот". Сдерживать эмоции надо вам.

>видимо, ты хорошо это скрываешь

я не собираюсь понтоваться перед тобой, какие книжки я читал и какие науки изучил.

> Писать свои фреймворки и CMS - удел ПХП разработчиков. Для питона есть великолепные фреймворки (Django, Pylons, Turbogears), которых хватает для всего круга задач.

Еще однин кодеманкей... Считаю обязанностью и правом любого программиста писать свои фреймворки, менеджеры итд сколько влезет и на любом языке.

> почитал оригинал и так и не понял, за чтов удалили следующие функции - apply()

Уже давно можно сказать func(*args, **kwargs). apply был сделан до появления этого синтаксиса.

> callable()

Появился ABC.

> coerce(), execfile(), file()

Могу только догадываться:

* coerce, скорее всего уехал в ABC, причем он должен стать куда круче. Хотя лично я им ни разу не пользовался. И даже не могу представить зачем он нужен.

* file (это точно???), скорее всего убран, так как open делает то же самое.

* execfile наверное отправиться по следам модуля compile.

> reduce()

Перенесен в модуль. functools вроде, лениво смотреть.

> reload()

Скорее всего отправится в какой--нибудь модуль. Или ipython и иже с ними реализуют его сами.

> Считаю обязанностью и правом любого программиста писать свои фреймворки, менеджеры итд сколько влезет и на любом языке

А, велосипедист со стажем?

> А, велосипедист со стажем?

И что в этом плохого? Наши вилосипеды самые велосипедистые. Хотя кодеманке это не понять, у нее велосипед 3 колесный и с сигнальчиком. Интересно, тот кто написал Django - тоже велосипедисты?

Обожаю сей язык. Лучшее для решения повседневных задач. Если бы не питон, я бы не занимал места на олипиадах :)

Ну вот хоть на куски меня режьте, не понимаю, как он может нравиться. Какая-то дикая смесь бейсика с паскалем. От него блевать охота, чесслово.

>Обожаю сей язык. Лучшее для решения повседневных задач. Если бы не питон, я бы не занимал места на олипиадах :)

школьнег? если ты занимаешь места на олимпиаде только благодаря питону - то ты их зря занимаешь...

вообще, смысла в этом споре нету, вы можете сколь угодно долго меряться пиписьками и рассказывать какой замечательный питон, но если встанет задача автоматизировать пивной ларек - любой вменяемый одинэсер порвет пытоншика как тузик грелку и получить денюжку, а пытонщик будет продолжать скулить на лоре. мне, например, уже абсолютно все равно какой язык лучше - у всех есть своя область применения. я видел кривые в жопу софтины на vb, которые тем не менее работали и видил быстрые высоконагруженные решения на жабе, которые работали по полгода без рестарта, и видел как на 1с за полчаса делаются вещи, которые на том же пытоне с нуля делались бы неделю. А еще целая армия народу ваяет на C#, и тот кто считает их всех кодемонками глубоко ошибается.

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

P.S. А вообще лисп рулит - он прошел проверку временем...

> школьнег? если ты занимаешь места на олимпиаде только благодаря
> питону - то ты их зря занимаешь...

С чего это зря. Это значит, что он больше над алгоритмом думает,
а не над распределением памяти и прочей хренью.

ну да, это правильно - ведь основной параметр, который тестируется на олимпиадах - кто быстрее сможет без динамической типизации - на убожестве типа C/pascal/java - закодировать некий алгоритм, который он также должен быстро вспомнить. это ли не соревнолвание code monkey?

dice.com

1408 == Python

14859 == Java

Счет 1:10.5 в пользу Джавы!!!

И это - в Кокосии-Америкосии!

:)))))

>Какая-то дикая смесь бейсика с паскалем.

Так может сказать только человек, который с бейсиком и паскалем знаком слабо, а питона не пробовал вообще.

> От него блевать охота, чесслово.

Это не от него. Пить надо меньше.

> ну да, это правильно - ведь основной параметр, который тестируется на олимпиадах - кто быстрее сможет без динамической типизации - на убожестве типа C/pascal/java - закодировать некий алгоритм, который он также должен быстро вспомнить. это ли не соревнолвание code monkey?

да ну - есть очень даже интересные олимпиады( у самого не одно призовое место по Украине по студенческим и школьным олимпиадам ), к примеру в Хмельницком мне нравилось участвовать потому-что там был большой спектр задач - и асм, и алгоритмы и математика, причем что было по умному сделано - так это то что программы оценивались кроме основных параметров( тестирование на некорректные входные данные, всевозможные частные случаи, большие значения и т.п. ) еще и по скорости выполнения, если программа работала идеально, но не влазила в определенный временной промежуток( а тестовые данные могли были очень большие ) - то результат не засчитывался полностью, вот тут как раз большинство monkey и отсеивалось, которые с умным видом требовали поставить им Visual, Java, VHDL( были и такие "умники" из Харькова ), Delphi и т.п., мне же ( как и другим вменяемым людям ) вполне хватало "убожеств" tasm, tlink и borland c