Fordítás sebességteszt

Clipper, CCC

A minap (pár hete) ellenőriztem a CCC installálását különféle rendszereken, azaz szakmányban végeztem C fordítást. A fordítás sebességében elég nagy eltérések adódtak, azért azt gondoltam, érdemes csinálni egy összehasonlító táblázatot. Íme: 


system                                      real   user

Fedora 20       PAE     Qemu   gcc.4.8.2   0m56s  0m27s
Arch            64-bit  Qemu   gcc.4.8.2   1m50s  1m27s
FreeBSD 10.0    64-bit  Qemu   clang-3.3   2m17s  1m37s
CentOS 6.5      64-bit  Qemu   gcc-4.7.7   2m13s  1m41s
Debian Wheezy   64-bit  Qemu   gcc-4.7.2   2m16s  1m47s
Ubuntu Precise  64-bit  natív  gcc-4.6.3   2m37s  1m55s
Ubuntu Saucy    64-bit  Qemu   gcc-4.8.1   2m43s  2m01s
NetBSD 5.1      64-bit  Qemu   gcc-4.1.3   2m40s  2m09s
SUSE 13.1       32-bit  Qemu   gcc-4.8.1   2m45s  2m14s
NetBSD 6.1      64-bit  Qemu   gcc-4.5.3   2m56s  2m18s
FreeBSD 8.4     64-bit  Qemu   gcc-4.2.1  10m12s  2m21s

A tesztben összesen 660 darab object fájl készült, aminek kb. 2/3-a volt generált (Clipper->C++) kód. Ezekből 124 darab végrehajtható program linkelődött.

A táblázat jobb oldali oszlopa a user time-ot mutatja, méghozzá 3 egymás utáni futtatásból a legjobbat. A user time növekvő sorrendjében vannak rendezve a sorok.

Megjegyzések:

1) Érthetetlen és hihetetlen, hogy a Fedora 20 (-on futó gcc) hogy lehet ennyivel gyorsabb a többinél. Viszont akárhányszor megismétlem a mérést, mindig ez jön ki. (Nincs véletlenül kihagyva a teszt egyik része sem. A keletkezett objectek újak és működőképesek.)

2) Az Arch jó eredményét viszont nem tudom reprodukálni. Az utólagos ellenőrzés során az Arch visszacsúszott a középmezőnybe. Újrainstalláltam, akkor is. 64 bit helyett 32 bites installáció, akkor is. A táblázatban az elsőre mért jó idők vannak.

3) A FreeBSD 10.0 a clang miatt gyorsabb az átlagnál.

4) Az egész teszt az Ubuntu Precise gépemen futó qemu-kvm-ben folyt. A natív Precise-on kapott idő a középmezőnyben van.

5) Negatív rekord a FreeBSD 8.4 kiugróan rossz real futásideje. Már a teszt indulásakor végzett clean (bele volt mérve a tesztbe) érthetetlenül lassú.

Következtetés:

Nem vonnék le semmilyen következtetést a fentiekből. Az Arch példája azt mutatja, hogy általam nem ismert körülmények szerencsés együttállása (vagy együtt nem állása) gyökeresen megváltoztathatja az erdeményt. Például nagyon valószínűnek tartom, hogy más installációkon a Fedora sem körözné le ennyivel a mezőnyt.

Szerk: Kiegészítve a CentOS 6.5-tel. Semmi meglepő.

( uid_7086 | 2014. 04. 01., k – 12:34 )

Engem az a qemu kicsit zavar a történetben.
Nem lehet, hogy az kavart be valamit?
Egyáltalán, ebben az esetben mire vonatkozott?
A másik: azért az sem mindegy, milyen kapcsolókat használsz fordításkor (utolsó emlékeim szerint az optimalizáció szintje befolyásolja a sebességet leginkább, de ez már nagyon rég volt), ezekkel mi volt a helyzet?

ui: lehet, hogy valamit totálisan félreértek az egészből?

Az összes rendszer (a precise kivételével) qemu virtuális gépen futott. A precise-on mért idő ezért kakukktojás. Elvileg gyorsabb lehetne, mint a többi, de a mérés azt mutatja, hogy mégsem gyorsabb. Vagyis a qemu-kvm virtualizáció elég hatékony.

A Linuxokon mindenhol -O1, a BSD-ken pedig -O2 optimalizáció volt beállítva.
--
ulysses.co.hu

A CCC3 egy részének a lefordításáról van szó. Maga a CCC3 letölthető innen: 


git clone  git://ccc.comfirm.hu/ccc3.git

Telepítés leírása (meglehetősen tömör): www.comfirm.hu/ccc3/ccc-belulrol.html

Amit konkrétan mértem, az az alábbi script futási edeje 


#!/bin/bash
#set -x

clean-all.b

i.b
if  find . -name error | grep error; then
    echo ERRORS
    exit 1
fi


if [ -d terminal/unix-ncurses ]; then #CCC3
    pushd terminal/unix-ncurses; m; popd
fi
if  find . -name error | grep error; then
    echo ERRORS
    exit 1
fi


pushd tools/sql2; i.b; popd
if  find . -name error | grep error; then
    echo ERRORS
    exit 1
fi

Ezt a CCC3 directoryból kell indítani.

--
ulysses.co.hu

( dejo v | 2014. 04. 01., k – 12:35 )

Egy CentOS-t is beletehettél volna, főleg, hogy RedHat sincs közte.
Azért köszi, hogy közzétetted a méréseidet, így is érdekes.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

( sigellef | 2014. 04. 06., v – 15:13 )

Itt inkább az a lényeg, hogy maga a g++/gcc milyen optimizálásal lett fordítva. Ez a mérés azt mutatja, hogy a Fedora 20 g++/gcc-je úgy van optimizálva, hogy az felel meg legjobban a processzorodnak.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

( mrev | 2014. 05. 02., p – 16:08 )

Tegnap átköltöztem precise-ról trusty-re. Ma az upgrade-del lejött egy csomó javítás, közte a qemu-kvm. Erről eszembe jutott, hogy ki kéne próbálni, működnek-e a qemu image-ek.

Egyelőre csak a Debian Wheezy-t és a NetBSD 6.1-et próbáltam (ugyanazok az img fájlok, ugyanazok az indítóscriptek). Bebootolnak, de a sebességből látható, hogy nincs virtualizáció, csak emuláció. A Wheezybe-be lehet ssh-zni, de a NetBSD-be nem. Ellenpróbaképpen bebootoltam a régi rendszerről (ugyanaz a hardver, ugyanazok az img fájlok, ugyanazok az indítóscriptek), ott minden működik.

A precise-on qemu-kvm 1.7.0 van, ami nekem jól működik.

A trusty-vel qemu-kvm 2.0.0rc1 jön, rossz. Kipróbáltam még forrásból fordítva ezeket: 1.7.0 nem fordul. 1.7.1 fordul, de a leírt hibákat produkálja. 2.0.0 leírt hibák. A 2.0.0 változat vívmánya, hogy parancssorból indítva csinál egy menüt a qemu ablakban.

--
ulysses.co.hu

Szerk.

Az megvan, hogy külön engedélyezni kell a virtualizációt, vagyis ez kell: 


sudo qemu-system-x86_64 --enable-kvm ...

Sajnos FreeBSD-n, NetBSD-n a hostfwd továbbra sem működik (Linuxokkal igen), azaz jeleneg nem lehet a BSD-kbe be-ssh-zni.

Van egy NetBSD 5.1 image fájlom, amit még natty-n csináltam anno. Miután precise-ra váltottam évekig nem tudtam bebootolni. A buglistákon látszott, hogy más is találkozott a jelenséggel. Először azt hitték, hogy NetBSD hiba, aztán rájöttek, hogy a qemu-kvm romlott el. Nem túl régen jött meg a javítás a precise-ba, és most tessék, a trusty megint nem jól futtatja a BSD-ket. Ezzel kell együttélni, néha működnek a dolgok, néha nem. Nem lehet rá számítani.

Szerk.

Megismételtem a tesztet az új gépemen (precise helyett trusty). Mindenki gyorsult. A Fedora továbbra is drasztikusan gyorsabb a többinél (nyilván nem a Fedora zsenialitása, hanem valami ismeretlen tényező miatt). Az Arch csak kicsit gyorsult, visszacsúszott a mezőnybe.

A FreeBSD 10.0, FreeBSD 8.4, NetBSD 6.1 rendszereken nem működik a hostfwd, nem lehet be-ssh-zni, ezeken a qemu konzolban futtattam a tesztet. A FreeBSD 8.4 kirívóan rossz real ideje megjavult (belesímult a mezőnybe), ez azt mutatja, hogy az előző tesztben mért lassúság az ssh kapcsolaton múlt. A NetBSD 5.1-ben (a 6.1-gyel szemben) viszont működik a qemu hálózat.

Kipróbáltam még két windows imaget. A W2K nem látja a (qemu)samba servert, a Windows-2012 szerver látja. Ezek a tapasztalatok azt mutatják, hogy a qemu hálózat egyes questek esetében működik, más esetekben nem.