Програмиране с Python

Python performance quiz

← 1 2 →

Ами ако 4GB са малко. :)

24.04.2009

Йордан Темелков
Ако кодиш на Java, е малко. Но сигурно не питаше това :)

24.04.2009

Стефан Кънев
Реших, че е време да спре да ме мързи и да замеря и моите времена.
```
timeit(f1) = 86.1185167389
timeit(f1) = tl
timeit(f1) = tl
timeit(f2) = 87.3287280925
timeit(f2) = tl
timeit(f2) = tl
timeit(f3) = 3.81631352588
timeit(f3) = 3.98506737588
timeit(f3) = 4.02472018092
timeit(f4) = 3.67637898113
timeit(f4) = 3.75541695942
timeit(f4) = 3.73370079158
timeit(f5) = 2.95582930233
timeit(f5) = 2.77023644066
timeit(f5) = 2.75785888989
```
Тестовете съм ги пускал в независима тестова сесия, с надеждата, че ще си влияят по-малко от колкото изпълнени един след друг в една тестова сесия.

Тестова конфигурация:

Python 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit (Intel)] on win32

CPU: Intel T7200 @ 2GHz

RAM: 2GB

OS: Windos Vista Version 6.0.6001 Service Pack 1 Build 6001

След като изпълних по един тест за 1-ва и 2-ра функция, с tl означих случаите, в които времето за изпълнение е очевидно дълго (над 20 сек.) и не съм дочакал края на теста.

Не наблюдавам чувствителна промяна в използваната памет по време на всички тестове, нито недостиг на такава.

Като стана на въпрос за Java се сещам за:

"Write Once, Run Everywhere"
—Sun Microsystems's mantra for Java

"Write Once, Test Everywhere"
—Cynical Java programmers

Може би и Python страда от второто? :-P

24.04.2009 (променeно 25.04.2009)
Атанас Атанасов

"Write Once, Test Everywhere" —Cynical Java programmers

Може би и Python страда от второто? :-P

Хех, по-скоро да. Също и:

"Write Once, Benchmark Everywhere" —Cynical Python programmers

slavi@slavi-desktop:~$ python3.0 what.py; python what.py
3.0.1+ (r301:69556, Apr 15 2009, 17:25:52) 
[GCC 4.3.3]
timeit(f1) = 5.58604693413
timeit(f2) = 5.7486178875
timeit(f3) = 6.67368197441
timeit(f4) = 5.89071416855
timeit(f5) = 5.23079395294
2.6.2 (release26-maint, Apr 19 2009, 01:58:18) 
[GCC 4.3.3]
timeit(f1) = 3.8531229496
timeit(f2) = 4.02928996086
timeit(f3) = 4.90220403671
timeit(f4) = 3.86598491669
timeit(f5) = 3.38645219803

На моята 3 годишна машинка AMD Athlon 3500+ 64bit с 1Gb RAM с 64bit Linux.

25.04.2009 (променeно 25.04.2009)

Славомир Къслев

И моята машинка:
CPU: C2D E8400 @ 3GHz
RAM: 4GB
OS: WinXP Pro SP3

Резултати на моята машинка, но с Mandriva 2009
3.0.1 (r301:69556, Apr 25 2009, 12:48:44)
[GCC 4.3.2]
timeit(f1) = 3.67198586464
timeit(f2) = 3.61054491997
timeit(f3) = 3.20080590248
timeit(f4) = 3.25754094124
timeit(f5) = 2.77153301239
Като гледам май ще трябва да се минава на Линукс. :)

25.04.2009 (променeно 25.04.2009)

Йордан Темелков
Значи f1 и f2 са толкова бавни само под Windows?

Някой друг останал, който да вярва, че на хората които разработват Python им пука за performance?

И за да не се повтарям:

Всеки спор относно, колко е бързо едно или друго в Python е просто ментална матрубация =-)

25.04.2009

Славомир Къслев
"Write Once, Benchmark Everywhere" —Cynical Python programmers

Само не мога да разбера за чий си ги мерите на различни python версии и различни конфигурации - 3.0rc1 vs 3.0.1 trunk vs 3.0.1 ... Честно казано и C кода на различни платформи AMD/Intel с различни OS-и и т.н. се държи различно...

Плюс това в python ако ви трябва performance (било то CPU/RAM) много лесно може да се обърнете до C код (живот и здраве ще имаме лекция по въпроса).

Също така кода на python е доста безпроблемен на портване (поне от моя опит, но аз пиша главно под linux) - говорим за чистия python код, не че за това GUI-то да ви изглежда еднакво под win и linux трябва да правите магии с графичните библиотеки gtk / wx /tk и т.н. (през същата процедура трябва да минете и ако пишете на C++).

Някой друг останал, който да вярва, че на хората които разработват Python им пука за performance?

А да и за разлика от Java (поне доколкото на мен ми е известно, ако някой знае нещо друго ще се радвам да прочета :) ), python си има benchmark тестове в source дистрибуцията/trunk, които се поддържат и се run-ват ;)

Далеч съм от твърдението, че не ме интересува каква е скоростта на python или че той е универсалния език...

Просто никой никога не го е замислял като бърз език (C), нито като паралелен език (erlang), нито като сигурен език (ADA) или пък пример на някаква "странна" методология (говоря за prolog)...

python се учи лесно, чете се лесно и се поддържа лесно, мощен е, идеален е да си напишете нещо което ви автоматизира някаква ваша работа - интелигентен parse на логове, сваляне на сайт и т.н., не да го пуснете в/у BlueGene да умножава матрици...

25.04.2009 (променeно 25.04.2009)

Точо Точев
Само не мога да разбера за чий си ги мерите на различни python версии и различни конфигурации - 3.0rc1 vs 3.0.1 trunk vs 3.0.1 ...

Последните няколко поста бяха от (почти +-5) еднакви svn ревизии.

Честно казано и C кода на различни платформи AMD/Intel с различни OS-и и т.н. се държи различно...

Да, ама не (в ранга на 40х забавяне).

Плюс това python ако ви трябва performance (било то CPU/RAM) много лесно може да се обърнете до C код...

Това бе и моя съвет преди няколко поста.

python си има benchmark тестове в source дистрибуцията/trunk, които се поддържат и се run-ват ;)

Явно windows port човека не знае (или не му пука за) това =-)

Далеч съм от твърдението, че не ме интересува каква е скоростта на python или че той е универсалния език... Просто никой никога не го е замислял като бърз език...

Именно. Аз обичам Python (r) (since 1998). Python си има своето залужено място в невероятно много области. Но не и когато се нуждаеш от performance. И това е нещо, което не се преподава в училище =-).

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

Python смуче яко откъм performance.

Трябва да има слайд с последното изречение. =-)

25.04.2009 (променeно 25.04.2009)

Славомир Къслев
@Славомир

Отговорите ми не бяха насочени към теб като критика, т.к. съм наясно, че разбираш какво пишеш, но не съм сигурен, че всички които четат разбират какво четат ;)

P.S. а за performance-а сме казвали на лекция

25.04.2009 (променeно 25.04.2009)

Точо Точев
@Славомир

И сега какво, ще ползваш обикновената конкатенация вместо join (когато пишеш за Linux)?

25.04.2009 (променeно 25.04.2009)

Атанас Атанасов
Просто винаги като пишеш, ползваш възможно най-елегантното и просто нещо, което работи. Нали на това му викаха Pythonic. Ако не си сигурен, import this. =-)

Така че join май е най-правилното в случая.

Ако наистина, ама наистина ти трябва performance, пиши на C. Ето един блог пост, в който пича разказва как може да се ползва C код от Python, без Python C API.

25.04.2009 (променeно 25.04.2009)

Славомир Къслев
Тогава, може би не е добра идея да разбиваш разни митове :-). Може някой водопроводчик, дето пише на/за Linux, да се подведе и да реши, че това е правилният стил на писане ;-)

25.04.2009

Атанас Атанасов

Може някой водопроводчик, дето пише на/за Linux, да се подведе и да реши...

Ами май Точо е прав, като каза че не пиша много ясно.

PS Couldn't resist =-)

slavi@slavi-desktop:~$ python3.0
Python 3.0.1+ (r301:69556, Apr 15 2009, 17:25:52) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import that
The Three Commandments of Python Performance

1. You shall never use Python when performance matters to you more
than beauty.
2. You shall never change elegant and simple code no matter what the
Profiler says, 'cause the Profiler says different things to different
people.
3. You shall never talk or listen to people bragging about Python
performance, 'cause those people are full of crap.

Python Church Addendum

If you sin, recite `import this` till your soul is pure again.
>>>

25.04.2009 (променeно 25.04.2009)

Славомир Къслев

← 1 2 →