python benchmark Windows 10/Windows Subsystem for Linux/Ubuntu 14.04

toMpEr inspirációjára... 

python -m test.pystone

Megnéztem, eredmények 100-100-100 futtatás után:

Diagram 


+----------------------+-----------------------------+--------------+--------------+
|                      | Windows Subsystem for Linux |  Windows 10  | Ubuntu 14.04 |
+----------------------+-----------------------------+--------------+--------------+
| python -V            | Python 2.7.6                | Python 2.7.6 | Python 2.7.6 |
| average              | 75149                       | 54248        | 100573       |
| min                  | 56140                       | 45088        | 95993        |
| max                  | 106667                      | 79229        | 102602       |
| 30000 <= x < 40000   | 0                           | 0            | 0            |
| 40000 <= x < 50000   | 0                           | 77           | 0            |
| 50000 <= x < 60000   | 1                           | 0            | 0            |
| 60000 <= x < 70000   | 68                          | 0            | 0            |
| 70000 <= x < 80000   | 0                           | 23           | 0            |
| 80000 <= x < 90000   | 2                           | 0            | 0            |
| 90000 <= x < 100000  | 4                           | 0            | 31           |
| 100000 <= x < 110000 | 25                          | 0            | 69           |
| 110000 <= x < 120000 | 0                           | 0            | 0            |
+----------------------+-----------------------------+--------------+--------------+

Üdv,
Marci

(szerk.: Windows 10-nél cseréltem az adatokat, ott is verzióra azonos Python verziót tettem fel.)

( toMpEr | 2016. 04. 11., h – 22:13 )

Köszi, a 3-as meg 2-es python eredménye nem annyira összehasonlítható, de valószínű windows alatt is linux-közeli eredményt kapnánk. Szóval kb 25%-os overhead lehet ami elég jó szerintem.

Nézd csak meg a diagramot is - szerintem más a helyzet, de nem értem, mi van a háttérben.
Az ábrán látható két további WSL kontrollfuttatás is: mindegyik a natív Ubuntu-val azonos teljesítménnyel indul, aztán egyszer csak mintha letekerné a teljesítményt egy láthatatlan kéz...
Amikor futtatom, jól hallható a dolog: felpörög a ventilátor, aztán visszavesz. Ubuntu alatt meg végig pörög...

Üdv,
Marci

Valami energiagazdálkodási varázslatnak tűnik.

Lefuttattam én is 100x a pystone-t, de nálam nincs jelentős csökkenés (win8.1 desktop):
Data num: 100, Min: 1.124s, Max: 1.256s, Avg: 1.149s

Linux alatt nincs túl nagy diff py2 vs py3 között, szóval a benchmarkod alapján simán lehet, hogy WSL-ben gyorsabban futnak a pythonos scriptek, mint pure win környezetben:

$ python -m test.pystone
Pystone(1.1) time for 50000 passes = 0.280506
This machine benchmarks at 178249 pystones/second

$ python3 -m test.pystone
Pystone(1.2) time for 50000 passes = 0.323335
This machine benchmarks at 154638 pystones/second

Szóval WSL-re felrakhatnád a python3-at (vagy pure win-re a py2-t) megnézni ott mennyit fut, hátha tényleg ad valami érdekes eredményt :)

( mrceeka v | 2016. 04. 11., h – 22:57 )

Valóban valami energiagazdálkodási csoda, de egyelőre nem találom, hol tudom kikapcsolni.
AIDA64 mutatja, hogy 2GHz körül megy a CPU, aztán hamarosan leesik 1.4GHz-re és ott is marad a script végéig.
Szóval ez pontosan magyarázza a különbséget. Ez alapján, ebben a mérésben, azonos CPU órajel mellett gyakorlatilag azonos a WSL és az Ubuntu teljesítménye.
WSL alatt kipróbálva a python 3.4.3-at, látszik, hogy sokkal lassabb, ami a Win10 eredményét tévesen lehúzza.

Üdv,
Marci

( asch v | 2016. 04. 11., h – 23:33 )

Nem olvastam végig a pystone kódját, csak belenéztem, de nekem úgy tűnik, hogy nem nagyon használ kernelhívásokat ez a program. Ha tehát különbség van a végrehajtás sebességében, az inkább a python interpreterből, vagy a libekből (vagy a processzor energiagazdálkodásából :-) adódik. Például ugyanazt a kódot az egyik esetben gcc-vel fordították, a másik esetben Microsoft C-vel. Vagy ilyesmi.

Olyan programmal lenne érdemes benchmarkolni, ami sok rendszerhívást használ. (Például valami hálózatkezelés, pipe-olás vagy leftpad :-). Így magunknak a rendszerhívásoknak az overheadje mérhetővé válik.

Szóval ha egy program nagyrészt elvan magában, és csak a CPU-t darálja, akkor jól teljesít. Remek.
Ha viszont az OS kernelnek is sokmindent kell csinálni, processzeket forkolni (ahogy általában shell scriptek teszik, ugye "Bash coming to Windows") és file-műveleteket végezni, akkor lassú vagy rettenetesen lassú. Kár, itt éreztem leginkább szükségesnek az előrelépést.

( hrgy84 | 2016. 04. 12., k – 21:21 )

Van valami nem-video alapu info errol a WSL cuccrol? Igazabol egy dolog erdekelne: az tiszta sor, hogy egy Ubuntut dugtak el a rendszer melyen, de ez mennyire tud interakcioba lepni a felette levo Windowssal? Ez egyfajta virtualizacio (inkabb szeparacios, mint technikai megvalositaskent ertem), vagy valami olyasmi, mint az SFU/Interix, csak jobbabb?
--
Blog | @hron84
Üzemeltető macik

Amennyire én értem, műszakilag ez tényleg egy subsystem a Windows-ban, ami lefordítja a Linuxos kernelhívásokat Windows-osra.
Ettől gyors is, kicsi a footprint is stb.
Ez nyitva hagyja az elvi lehetőséget a mélyebb interakcióra, de ma nincs semmi ilyen, ugyanis az Ubuntu userspace fut rajta, ami (nem meglepően) még nem rendelkezik ilyen funkciókkal.

Jelenleg ami interakció van, az a file rendszerek átjárhatósága két irányban.

Ha jól érzem, a "Mi lesz?"-t erősen befolyásolja majd, hogy milyen visszajelzés érkezik, úgyhogy: Feedbackre fel!

Üdv,
Marci

A D-Bus-on keresztuli vezerelhetoseg peldaul nagyon jo otlet, peldaul az Ubuntu elindithatna a Windowson egy media playert, OLE szinten atadva a jatszando videot/zenet/whatevert.

Vagy gondoljunk az MSSQL OLAP kezelesere, ami jelenleg kizarolag a Windowsos MSSQL driverben van meg, a Linuxos driver kepessegei e teren meglehetosen szerenyek. Es mivel elmozdulas errol a pontrol evek ota nem latszik, igy ez kisse egyszerubbnek tunik, mint rimankodni az MS-nek, hogy "leccilecci legyen mar".
--
Blog | @hron84
Üzemeltető macik

Igen, az OLAP-ra egyszerubb lenne, ha az MS megeroltetne magat, es kiadna egy rendes drivert Linuxra.
A medialejatszasban csak probaltam emberkozeli otletet hozni. A grafikus rendszert valoszinuleg egyebkent nem a legjobb otlet Linux oldalon tolni, az az emulacio/transzlacio/whatever miatt mindenkeppen rosszabb elmenyt hoz. Akkor inkabb a Windows legyen a grafikus host.

Raadasul kerdes, hogy a Linuxos grafika mennyire seamless integralodik a Windowssal. Ketlem, hogy az X hivasok is keresztforditva lennenek, annak pedig nincs sok jovoje, hogy egy keretben nezegessem a zenelejatszot. Szemely szerint akkor inkabb megoldom a D-Buson keresztuli iranyitasat a Windowsos lejatszonak.
--
Blog | @hron84
Üzemeltető macik