Enyhén lebőgött a python

Enyhén lebőgött a python
2016-08-05T21:54:50+02:00
2016-08-07T13:40:52+02:00
2022-10-20T07:00:33+02:00
  • Na ez az nbody teszt is ott lett elszurva, hogy nincs megkovetelve a pontossag.
    Hiaba hasznal mindenhol double-t, ott ahol a tavolsag kiszamitasa van, az elso 7 versenyzo (jellemzoen 10 masodperc kiveve az ADA mert az annyira tré, hogy ezzel a cheat-el is csak 18 :D) tehat az elso 7 versenyzo egyszeruen csal, mert az 1/sqrt(x)-et ugy szamolja ki, hogy eloszor lekonvertal double-bol single-be, majd pedig meghivja rá az 1/sqrt(x) kozelitest, ami csak 3 tizedes pontossagu. Naná, hogy igy nem 50 cycle, hanem csak 1 :D

    Ezeket jonnek a 20 masodperces versenyzok, ami kivetel nelkul double precision high level kodot forditanak, de sajnos vektorizacio nelkul, ugyanis a programokban array of struct a felallas, nem pesid struct of arrays. De ott aztan nagyon szoros a verseny, legyen az akár FreePascal, C# vagy GCC.

    Nalam ilyen idok jottek ki: (Egyik forrasban sincs asm/intrinsics, szoval itt a fordito szamit)

    FPascal 5.86s fpu math, no exception checking Delphi XE3 win32 7.45s fpu math, exception checking after each operation (fwait) Delphi XE3 win64 3.35s sse single data math (implicit exception checking) MSVC2013 win32 3.80s sse single data math (a bit less optimal than dxe3/64)
    Sajna a Delphi win32 compilere elavult lett float matekra: fpu utasitasokat hasznal sse helyett (Az fpu stack miatt az instruction level paralellism felejtos.) Es raadasul minden muvelet utan fwait-ol, hátha floating point error volt. Az FPC ezzel szemben nem foglalkozik az errorral, hanem kuldi tovabb az esetleges NAN-okat. A DelphiXE3 64bites forditoja viszont remek float kodot general, kicsit valamiert (azt mar lusta voltam megnezni:D) le is hagyta az MSVC2013 32bites kodjat (ami szinten sse), de gondolom a 64bites MSVC-vel fej fej mellett lehetnek. A leggyorsabb nyelvet jsfiddle-ben probaltam ki, ami kb. 5-6 sec lett, ezaltal mejdhogynem veri a FreePascalt. :D
    (teszt cpu: FX8350)
    Mutasd a teljes hozzászólást!
  • A pythonban vannak rendes strukturák?

    Alapesetben a class példányok mezői hash táblában tárolódnak, szóval elég lassú. Viszont elvileg lehet "igazi" struct memóriakiosztást kérni neki a __slots__ használatával:

    class BarmiMezoLehetBenne: pass class CsakFixMezok: __slots__ = ['foo', 'bar', 'baz'] test = CsakFixMezok() test.foo = 42 test.bla = 42 #AttributeError: 'CsakFixMezok' object has no attribute 'bla'
    Azon viszont ez sem segít, hogy minden mező mutatóként van implementálva, hiszen tetszőleges Python értékre mutathat, nem korlátozhatod le a mezők típusát.
    Mutasd a teljes hozzászólást!
  • Hi,

    Beleneztem ebbe az n-body-ba es par tesztet en is akarok majd csinalni...
    Ez tömény matek, a perl pedig szerintem ott bukik el, hogy a rengeteg hivatkozott operandus ott ha jol gondolom mind variant. Plusz a sok tomb indexeles is ellenorizgetve lehet mindig.

    Még egy tipp: A pythonban vannak rendes strukturák? Vagy azok csak asszociativ array-szerusegek (mint pl az en scriptemben). Na ha az utobbi, akkor az is nagyon belassithat.
    Update: Most neztem meg: ez az assoc arrayban az array-ban az array dolog eléggé kinyírja. Nem csoda, hogy az eredmény irtozatosan környezetterhelô :D
    Mutasd a teljes hozzászólást!
  • A python3 -al kapcsolatban lepett meg, bár nem minden van agyon optimalizálva ott sem (pl a statistic() nem a gyorsaságra, hanem a pontossagra van kihegyezve, stb, de mégis). 
    Mutasd a teljes hozzászólást!
  • Én is inkább a meglepetéseden csodálkozom. Igen, a default CPython implementáció meglehetősen lassúcska. De hogy ez egy főállású python fejlesztőnek ekkora meglepetést okozzon...
    Mutasd a teljes hozzászólást!
  • Az SO válasz érdekes, de szerintem nem igazán zárja ki a hibás metodikát. Azt pedig, hogy belinkeled a forráskódot, amire írtam, hogy nem néztem meg (!= nem találtam), nem is igazán értem.

    EDIT: Annyit akarok csak mondani, hogy még ha adott is egy olyan valós probléma, ami CPU v. memória limites, akkor sem szabad ezeket a benchmarkokat szentírásnak venni, mert csak komolyabb kutatómunkával lehet helyesen értelmezni az eredményeket.
    Mutasd a teljes hozzászólást!
  • de kíváncsi vagyok, hogy mi az oka annak, hogy a C++ két nagyságrenddel több memóriát foglal mint a free pascal, mikor szinte semmilyen memória-igényes absztrakciót nem használ.

    libc

    Does Freepascal really use *far* less memory than gcc

    Nem néztem meg forráskódokat,

    http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&..


    http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&..

    vagy pedig rossz körülmények között futnak a tesztek (például zajos szomszéd mellett egy VPS-en)

    http://benchmarksgame.alioth.debian.org/how-programs-are-measured.html
    Mutasd a teljes hozzászólást!
  • A "szebb" kód is 2-3-szor gyorsabban lefut.

    #include <algorithm> #include <iostream> #include <vector> #include <boost/iterator/counting_iterator.hpp> #include <boost/timer/timer.hpp> int main() { constexpr int x = 10000; constexpr int y = 1000; boost::timer::cpu_timer t; t.start(); for (int i = 0; i < y; ++i) { auto a = std::vector<int>(boost::make_counting_iterator(1), boost::make_counting_iterator(x + 1)); std::reverse(a.begin(), a.end()); std::sort(a.begin(), a.end()); } std::cout << t.format() << '\n'; }
    Mutasd a teljes hozzászólást!
  • Sajnos tényleg katasztrofális, legalábbis ami a tömböket illeti:

    How big are PHP arrays (and values) really? (Hint: BIG!)

    PHP 7-tel sokat javult a helyzet, de tetszőleges scriptnyelvhez képest még mindig szörnyű:

    PHP's new hashtable implementation


    Ez persze nem jelenti azt, hogy senki ne használjon weboldalak kiszolgálására PHP-t, csak annyit állítok, hogy bennem komoly kétségek ébredtek a teszt megbízhatósága kapcsán.
    Mutasd a teljes hozzászólást!
  • Ez szintetikus teszt ha jól tudom.

    Egyébként a tesztben az a fura, hogy a több magos procit csak pár nyelv használta ki.

    Nem fedi le a valós használatot. De igaz, hogy a Python a leglassabbak között van.
    Én úgy tekintek a programozási nyelvre, mint egy tool/eszköz, és a feladat határozza meg, hogy melyik toolt fogom használni, melyik a legjobb eszköz a feladat elvégzésére.

    Példa: Elixir a single-threaded tesztekben eléggé csak a közép mezőnyben van, ahogy ilyen teszteket olvasok, de multi-threded-ben már ott van az élmezőnyben (az Erlang is ilyen).

    Lassú a Python, de a Youtube-nál is az előnyét használják ki :P. Tégy te is így!
    Mutasd a teljes hozzászólást!
  • Az is gyanús, hogy fej-fej mellett van a memória-foglalás az ebben a műfajban legendásan rossz PHP-vel.

    Nekem nem :). Alapjáraton a PHP beéri kevesebb memóriával is, sőt tényleg ilyen keveset eszik. Saját fejlesztésű weboldalak teljesítményénél látom, úgy hogy komolyabb kép manipulálás van mögötte (méret módosítás, pixelek módosítása). Igaz nem statisztikai elemzést végzek de arra ott a Julia.

    Ha sok memóriát eszik a PHP (és nem indokolja semmi sem), akkor ott hibát követett el a fejlesztő vagy rossz library-t használt.

    Ilyen szintetikus tesztnél ez teljesen jó memória használat a PHP-től. Ráadásul a PHP gyorsabb nyelv mint a Ruby és a Python.
    Mutasd a teljes hozzászólást!
  • Nem értem, min csodálkozol. Dolgozol egy nyelvvel és puszta kíváncsiságból nem nézted át benchmarkok tucatjait? Én eddig akárhány benchmark-ot láttam, a Python mindig a végén kullogott. Persze többféle Python implementáció is van, de egyik sincs a C, C#, Java szintjén, de a sebességet tekintve még a JS is agyonveri. A Python alapvetően a PHP-vel és Ruby-val van egy ligában a sebesség terén. Persze ez erősen Python implementáció függő, mint ahogy teszem azt a PHP-nél se mindegy, hogy HHVM-en fut-e.

    Most hiába keresem azt a honlapot, ahol egészen részletes tesztek voltak egy rakás programnyelvről, de szerintem kiindulási alapnak ezek se rosszak:
    Performance of several languages
    Programming Languages Benchmarks

    Érdemes minél több hasonló oldalt felkeresni, és egyre jobban ki fog kristályosodni, hogy a Python számtalan előnyének nem része a sebesség.
    Mutasd a teljes hozzászólást!
  • Nálam a teszt.cpp 0.54 alatt fut, míg a python 1.77 alatt.. (parancssorból mérve, egyik kódon sem változtatva semmit)
    Mndjuk nem csoda, mert nem is ugyanazt csinálják a kódok, de azért kíváncsi lennék, hogy neked hogy győzött a python :)

    Optimalizálatlan C++ kód nálam is lassabb pár tizeddel.
    1.89s, viszont O3-al fordítva már pár tized mádodperc alatt lefut az egész ~0.4-0.5
    Mutasd a teljes hozzászólást!
  • C++-ban hogy mérted az időt?
    Vagy ott egész alkalmazást mérted a runtime felállásával, meg eltakarításával együtt? :)
    Ez csak egy a pontok közül..

    pl. nálam több tized másodperc a különbség a python kód által mért és parancssorból mérve a python kód futtatása közötti különbség..

    1.47 seconds command 0:0:1.87 (1.87s total)
    Mutasd a teljes hozzászólást!
  •     for (int j = 0; j < y; j++){
            for (int i = 0; i < x; i++){
                b = x - i;
            } // még mindig lassúbb, mint a python

    szerinted a python mögött futó kód mennyire van agyonoptimalizálva és párhuzamosítva?
    Mutasd a teljes hozzászólást!
  • látom téged is megfertőzött házigazdánk azzal, hogy kényszeresen bizonyítani akarod, miszerint egy interpreteres/közteskódos runtime fordított mendzselt akármi gyorsabb mint bármi más, ami helyből a vas felett van 
    Mutasd a teljes hozzászólást!
  • Ennek a benchmarknak csak ma fogom átnézni és kielemezni rendesen a forráskódját. Oszt majd okosabb leszek.

    De ha én írok tesztet, akkor a python jön ki győztesen:
    #!/usr/bin/env python3 from time import time x = 10000 y = 1000 start = time() for _ in range(y): a = list(range(x)) a.reverse() a.sort() print(round(time() - start, 2), 'seconds')
    teszt.cpp
    using namespace std; #include <iostream> #include <algorithm> int main() { int x = 10000; int y = 1000; int b[10000]; cout << "start" << endl; for (int j = 0; j < y; j++){ for (int i = 0; i < x; i++){ b[i] = x - i; } // még mindig lassúbb, mint a python sort(b, b + x); // regular sort } cout << "done"; }
    test-reverse.cpp
    using namespace std; #include <iostream> void merge(int * arr, int *temp, int first_start, int second_start, int second_finish) { int a1 = first_start, b1 = second_start, r = 0; while (a1 < second_start && b1 < second_finish) { if (arr[a1] < arr[b1]) { temp[r] = arr[a1]; a1++; r++; } else { temp[r] = arr[b1]; b1++; r++; } } if (a1 < second_start) { while (a1 < second_start) { temp[r] = arr[a1]; a1++; r++; } } else { while (b1 < second_finish) { temp[r] = arr[b1]; b1++; r++; } } for (int i = first_start; i < second_finish; i++) { arr[i] = temp[i - first_start]; } } void merge_sort(int *a, int a_len, int *temp) { int c = 1, start = 0; while (c < a_len) { while (start + c * 2 < a_len) { merge(a, temp, start, start + c, start + c * 2); start += c * 2; } if (start + c <= a_len) { merge(a, temp, start, start + c, a_len); } c *= 2; start = 0; } } int main() { int x = 10000; int y = 1000; int b[10000], temp[10000]; cout << "start" << endl; for (int j = 0; j < y; j++) { for (int i = 0; i < x; i++) { b[i] = x - i; // még mindig lassúb mint a python } merge_sort(b, x, temp); } cout << "done"; }
    Mutasd a teljes hozzászólást!
  • Arra akarok kilyukadni, hogy 90%, hogy rossz a teszt.

    szerintem meg 100%, mert köztudott, hogy a javascript még a c++ -nál is gyorsabb

    azt se értem, hogy miért van 7 különböző, rendkívül eltérő futási időt produkáló C# kód.

    ezt a kódot nézve én elsőre a GC-re gyanakodnék.
    ennyi felesleges lefoglalást/felszabadítást még életemben nem láttam
    az iterációk számát tekintve egész biztos gigabyte-os mértetkről beszélünk
    Mutasd a teljes hozzászólást!
  • Azzal együtt, hogy a python valóban borzasztóan lassú, és minden teszt szerint legalább egy nagyságrenddel lassabb mint egy gépközelibb nyelven megírt azonos kód (feltéve persze, hogy a probléma CPU limites), nekem elég gyanús ez a teszt.

    Nem néztem meg forráskódokat, de kíváncsi vagyok, hogy mi az oka annak, hogy a C++ két nagyságrenddel több memóriát foglal mint a free pascal, mikor szinte semmilyen memória-igényes absztrakciót nem használ.

    Az is gyanús, hogy fej-fej mellett van a memória-foglalás az ebben a műfajban legendásan rossz PHP-vel.

    Ha a "KB" oszlop nem az átlagos v. top memóriafogyasztás mutatja, akkor persze benéztem. 

    Fura az is, hogy a Rust ennyire hátul végzett, és hogy a Go ennyire elől (futási időben), hogy a C++ fordítók dupla olyan gyors kódot csináltak mint a C-k, és azt se értem, hogy miért van 7 különböző, rendkívül eltérő futási időt produkáló C# kód.

    Arra akarok kilyukadni, hogy 90%, hogy rossz a teszt. Vagy az algoritmusok nem ekvivalensek, vagy pedig rossz körülmények között futnak a tesztek (például zajos szomszéd mellett egy VPS-en)
    Mutasd a teljes hozzászólást!
  • Egy érdekes benchmark tesztet találtam a neten és mit mondjak? Szinte el sem akartam hinni. Az vigasztal, hogy legalább a gnu c toppon van.

    Nézzétek meg: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=nb..
    Forráskód: http://benchmarksgame.alioth.debian.org/download/benchmarksgame-sour..
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd