Fordítás sebességteszt

Clipper, CCC
  • 6574 megtekintés

( 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.