Raspian contra Debian armel

[schorsch_76]

Hallo Zusammen!

Ausgangssituation:
Auf einem meiner Raspis lauft momentan Raspian. Er macht momentan openvpn, Wechselrichterabfrage und anderen Kleinkram. munin zeigt dass er eigentlich die meiste Zeit idle hat.

Raspian ist natürlich für armv6+vfp mit hard float abi kompiliert. Nutzt also die Hardware ideal aus. Jetzt hab ich auf dem "Spielzeug" RPi Debian armel installiert über ein qemu image und dann Firmware integriert. Kernel musste auch ausgetauscht werden, da die bcm_2708 Sachen nicht enthalten waren.

Eigentlich will ich meine Kisten mit Debian laufen lassen, da hier ja wirklicher Security Support vorhanden ist. "Leider" ist armel für armv4 und soft abi kompiliert (also ArmEAbiPort). armhf braucht eine andere FPU als der RPi sie hat. Wisst ihr wie die Situation mit Security Updates etc bei Raspian ist? Wie handhabt ihr das?

Gruß
schorsch

[1] http://wiki.debian.org/ArmHardFloatPort
[2] http://wiki.debian.org/ArmPorts

[cosmac]

hi,

Wisst ihr wie die Situation mit Security Updates etc bei Raspian ist?

spannende Frage! Im offiziellen Teil von raspbian.org finde ich praktisch nichts zum Thema security. Solche Tipps sind ja eher deprimierend:

Configure the package manager

The repository on security.debian.org couldn't be accessed, so its updates will not be made available to you at this time. You should investigate this later.
<Continue>

was natürlich auch heißen kann, dass die security updates sofort in "archive.raspbian.org/raspbian wheezy main" auftauchen; aber das hätte man ja erwähnen können.

Aber im IRC findet sich (ab ca. [2:45]) eine interessante Aussage:

as I said the vast majority of changes that go into debian wheezy go into raspbian wheezy within 12 hours

Raspian ist natürlich für armv6+vfp mit hard float abi kompiliert. Nutzt also die Hardware ideal aus.

Und wieviel bringt das im wirklichen Leben? Speziell den Unterschied zwischen raspbian und armel müsste man mal mit echten Anwendungen "benchmarken". So wie ich die ARM FP Hardware verstehe, werden Programme, die kein FP brauchen eher langsamer, und das sind doch die meisten. Andererseits wird es wohl noch andere Optimierungen geben.

raspbian dürfte einfacher zu installieren sein. Das könnte für mich den Ausschlag geben, wenn ich "jetzt sofort" ein laufendes System haben will. Normal wäre mir armel sympathischer.

[schorsch_76]

Mir ist armel im Prinzip auch lieber. Hier ist die Situation halt ganz klar.

Eigentlich(tm) müsste für eine reibungslose armel Installation nur ein Raspi Kernel bereitgestellt werden und ein Raspi Target für qemu-system-arm. Der versatile Kernel aus armel ist afaik für eine spezielle Konfig gedacht. Siehe auch [1]. Bzw. die anderen linux-images wie orion5x und co.

Raspi ist natürlich einfach installiert. Image ziehen, dd und go.

Werde heute abend mal bischen auf den zwei RPis mal verschiedene Tests laufen lassen. Was wäre den hier interessant?

*grübel*

Gruß
schorsch

[1] http://packages.debian.org/search?suite ... inux-image

[syssi]

Raspian ist natürlich für armv6+vfp mit hard float abi kompiliert. Nutzt also die Hardware ideal aus.

Und wieviel bringt das im wirklichen Leben? Speziell den Unterschied zwischen raspbian und armel müsste man mal mit echten Anwendungen "benchmarken". So wie ich die ARM FP Hardware verstehe, werden Programme, die kein FP brauchen eher langsamer, und das sind doch die meisten. Andererseits wird es wohl noch andere Optimierungen geben.

Ich habe mich auch noch nie mit FPUs auseinandergesetzt aber meine Idee davon war bisher umgekehrt: Wenn eine CPU keine FPU besitzt, dann muessen alle arithmetischen Operationen mit Fließkommazahlen von einer Implementierung in Software auf der CPU gerechnet werden. Das eine Anwendung keinerlei FP-Operationen benoetigt ist doch eher selten, nicht? Fragt man XBMC-Enthusiasten, dann liegt ein spuerbarer Unterschied zwischen den beiden "Architekturen".

Gruss syssi

[cosmac]

Wenn eine CPU keine FPU besitzt, dann muessen alle arithmetischen Operationen mit Fließkommazahlen von einer Implementierung in Software auf der CPU gerechnet werden.

ja, klar, aber nur diese. Für ganze Zahlen und Text macht es keinen Unterschied. Allerdings gibt es die FP Hardware nur einmal, deshalb müssen alle Register bei jedem Task-Wechsel gesichert werden; das könnte (speziell auf der ARM-CPU) jedes Programm bremsen.

Aber viel entscheidender ist der Programm-Mix. Ich dachte vorhin mehr an Webserver, Compiler oder so. Dabei hab' ich vergessen, dass z.B. GTK relativ viel Fließkomma verwendet, und daher werden normale Desktop-Benutzer und XBMC-Enthusiasten sehr wohl einen Unterschied merken.

[syssi]

Wenn eine CPU keine FPU besitzt, dann muessen alle arithmetischen Operationen mit Fließkommazahlen von einer Implementierung in Software auf der CPU gerechnet werden.

ja, klar, aber nur diese. Für ganze Zahlen und Text macht es keinen Unterschied. Allerdings gibt es die FP Hardware nur einmal, deshalb müssen alle Register bei jedem Task-Wechsel gesichert werden; das könnte (speziell auf der ARM-CPU) jedes Programm bremsen.

Verstehe und ergibt Sinn.

[schorsch_76]

Ich mach mit ein C/C++ Testprogram, das einmal bsp. 1 Mio Float ops macht und bsp 1 Mio Integerops. Das sollte ja genau diese FPU Stärke/Schwäche zeigen. Alles andere wäre subjektiv.

[schorsch_76]

Ok,
das hier ist das Testprogramm [1]. Ergebnisse sind in Sekunden.

Ein Cycle ist 1Mio mal die Addition/Subtraktion/Multiplikation/Division zweier int/float/double Werte. Alle Werte sind im Speicher.

Raspian nutzt GCC 4.6.3
Ergebnisse Raspbian:

Code: Alles auswählen

./src/int-fpu-test 100
Init Arrays:    2
Running 100 Cycles ...
Int Test:       38
Float Test:     38
Double Test:    51

Debian armel nutzt ebenfalls GCC 4.6.3
Ergebnisse Debian armel:

Code: Alles auswählen

./src/int-fpu-test 100
Init Arrays:    3
Running 100 Cycles ...
Int Test:       39
Float Test:     78
Double Test:    171

Wie man sieht ist die Intleistung praktisch gleich, aber die Float und Double Leistung ist unglaublich in den Keller gegangen. float = 2.05x armhf und double = 3.35x armhf

Jetzt werde ich wohl noch cos/sin und co hinzufügen... aber das Ergebniss dürfte ähnlich ausfallen.

Gruß
schorsch

37171

[schorsch_76]

Zum Vergleich ein alter Via Prozessor: Debian Wheezy i386 mit 486 Kernel.

Code: Alles auswählen

cat /proc/cpuinfo 
processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 7
model name      : VIA Samuel 2
stepping        : 3
cpu MHz         : 399.000
cache size      : 64 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu de tsc msr cx8 mtrr pge mmx 3dnow
bogomips        : 799.94
clflush size    : 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual
power management:

Code: Alles auswählen

./src/int-fpu-test 100                                                                          
Init Arrays:    2                                                                                                                    
Running 100 Cycles ...                                                                                                               
Int Test:       58
Float Test:     77                                                                                                                   
Double Test:    101  

[schorsch_76]

Und mein alter Amd Geode LX.
Ebenfalls wheezy/i386 mit 486 Kernel

Code: Alles auswählen

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 5
model           : 10
model name      : Geode(TM) Integrated Processor by AMD PCS
stepping        : 2
microcode       : 0x8b
cpu MHz         : 497.999
cache size      : 128 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow
bogomips        : 995.99
clflush size    : 32                                                                                                                 
cache_alignment : 32                                                                                                                 
address sizes   : 32 bits physical, 32 bits virtual                                                                                  
power management:                    

Code: Alles auswählen

./src/int-fpu-test 100
Init Arrays:    2
Running 100 Cycles ...
Int Test:       38
Float Test:     54
Double Test:    67

[schorsch_76]

Bei der integer und float/double Leistung ist der armhf (Raspbian) Raspi vorne auf. Unglaublich.

[syssi]

Ich dachte ja immer, dass mein Pogoplug E02 es mit einem Raspberry Pi aufnehmen koennte. Scheint aber nicht der Fall zu sein:

Code: Alles auswählen

$ cat /proc/cpuinfo
Processor       : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS        : 1191.11
Features        : swp half thumb fastmult edsp 
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1

Code: Alles auswählen

$ g++ test.cpp 
$ ./a.out 
Init Arrays:    2
Running 1000 Cycles ...
Int Test:       309
Float Test:     662
Double Test:    1335

Mit Hilfe von Compiler-Flags laesst sich auch fuer mich noch ein wenig was rausholen:

Code: Alles auswählen

$ g++  -Ofast test.cpp 
$ ./a.out 
Init Arrays:    1
Running 1000 Cycles ...
Int Test:       207
Float Test:     543
Double Test:    1192

[schorsch_76]

Was man hier nicht vergessen darf, dass dieser Test nicht SSE/MMX und Co (also SIMD) nutzt. Sondern einfach alle Zahlen einzeln behandelt, aber diese Embedded Prozis haben ja praktisch kein SSE. Gut der Geode hat MMX/3dnow. Hier könnte evtl. noch was gehen. Weis nicht wie viel hier der g++ optimiert da die schleifen ja wirklich vorhersagbar sind.

Gruß
schorsch

[wanne]

Die test's sind eher unrealistisch. Weil relativ wenige Variablen immer wieder genutzt werden. Und wenn du da -funroll-loops und -O3 drüber jagst düber jagst dürfte da sowieso nicht mehr viel übrig bleiben.
Würde eher so testen (Integer berechnungsintensiv):

Code: Alles auswählen

time dd if=/dev/zero count=1 bs=$((1023*2**21)) | openssl bf -bf-ecb -k test -out /dev/null

(float intensiv (glaube ich)

Code: Alles auswählen

time ffmpeg -i test.wav out.mp3

Edit: wenn ich das richtig sehe haben die jede Menge assemblert. Auch für bf. Kapier aber nicht ganz wie der bei nicht 32Bit x68 reagiert. (Er erstellt entsprechende bynarys kann mir aber nicht vorstellen, dass die i586.pl für solche Targets Baut.

[schorsch_76]

Das hat ja syssi gemacht mit -Ofast.... Mir ging es nur um den Test der ABI. Der Rest war ja nicht interessant

[wanne]

Das hat ja syssi gemacht mit -Ofast.... Mir ging es nur um den Test der ABI. Der Rest war ja nicht interessant

Das was ich halt Problematisch an deiner Methode halte ist folgendes:
Wenn du irgendwie sowas hast:

Code: Alles auswählen

for(int n=0;n<10000;n++){
  uint32_t i=300;
  i*=i;
}

Dann hast du bei -O0 das problem dass das dir jedes mal die pipeline killt. Sprich dein Amd Geode LX, mit sehr langer Pipeline, arbeitet die meiste Zeit gar nicht sondern wartet, dass das alte Ergbnis zur Verfügung steht.
Bei -O3 hast du das Problem das er dir die Schleife einfach wegoptimiert.

[schorsch_76]

Dann kuck nochmal in den Quellcode .... das ist definitiv falsch.

[DeletedUserReAsG]

Ich dachte ja immer, dass mein Pogoplug E02 es mit einem Raspberry Pi aufnehmen koennte. Scheint aber nicht der Fall zu sein: […]

Naja, schorsch_76 hat’s nur 100x durchlaufen lassen. So gesehen schlägt es das Pi also durchaus …

cu,
niemand

[wanne]

Habe den Source nicht gesehen aber zumindest das erste Problem ist drin:

Code: Alles auswählen

for (i = 0; i < array_size;++i)
                        g_double3[i] = g_double1[i] + g_double2[i];

Einzelne Addition; Sprung; Einzelne Addition; Sprung... (mit O3 dürfte das gcc dir das aber beseitigt haben.)
Und das zweite hast du dadurch ersetzt, dass er jetzt ziemlich schnell durch den speicher läuft, sodass mitunter der das bottleneck sein kann. Wobei das bei den alten CPUs noch nocht so Problematisch war weil die selbst lahm sind.

[syssi]

Ich dachte ja immer, dass mein Pogoplug E02 es mit einem Raspberry Pi aufnehmen koennte. Scheint aber nicht der Fall zu sein: […]

Naja, schorsch_76 hat’s nur 100x durchlaufen lassen. So gesehen schlägt es das Pi also durchaus …

Stimmt. Ich habe die paar Zeilen Code nochmal mit 100 Runden laufen lassen:

Code: Alles auswählen

$ ./a.out 
Init Arrays:    2
Running 100 Cycles ...
Int Test:       30
Float Test:     64
Double Test:    141
$ g++ -Ofast test.cpp 
$ ./a.out 
Init Arrays:    1
Running 100 Cycles ...
Int Test:       19
Float Test:     53
Double Test:    116
$

Ich bleibe dem Pogoplug also weiter treu.

Gruss syssi

[schorsch_76]

Nachdem ich mal wieder mit den RPi beschäftigt habe, habe ich einen besseren Performancetest gefunden. [1]

Der RPi macht mit 700 MHz wie hier beschrieben um 43000 KFLOPS mit Rasbian.

Raspian:

Code: Alles auswählen

./linpack 
Enter array size (q to quit) [200]:  
Memory required:  315K.


LINPACK benchmark, Double precision.
Machine precision:  15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:

    Reps Time(s) DGEFA   DGESL  OVERHEAD    KFLOPS
----------------------------------------------------
      16   0.56  89.29%   1.79%   8.93%  43084.967
      32   1.11  89.19%   4.50%   6.31%  42256.410
      64   2.22  88.74%   4.05%   7.21%  42666.667
     128   4.44  89.19%   2.70%   8.11%  43084.967
     256   8.87  88.61%   3.83%   7.55%  42874.797
     512  17.74  88.67%   2.99%   8.34%  43243.952

Debian Armel:

Code: Alles auswählen

root@debian-armel:~# ./linpack 
Enter array size (q to quit) [200]:  
Memory required:  315K.


LINPACK benchmark, Double precision.
Machine precision:  15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:

    Reps Time(s) DGEFA   DGESL  OVERHEAD    KFLOPS
----------------------------------------------------
       4   0.71  91.55%   2.82%   5.63%   8199.005
       8   1.42  91.55%   2.11%   6.34%   8260.652
      16   2.84  90.85%   2.82%   6.34%   8260.652
      32   5.68  91.20%   2.99%   5.81%   8214.330
      64  11.35  90.75%   2.82%   6.43%   8276.208

Man sieht das das ABI sehr deutlich was ausmacht. zwischen 8200 KFLOP und 43000 KFLOP ist schon was. Faktor 5. Wow!

Hier noch etwas Offtopic: Vergleich auf dem i7:

Code: Alles auswählen

cc -O3 -o linpack linpack.c -lm

./linpack 
Enter array size (q to quit) [200]:  
Memory required:  315K.


LINPACK benchmark, Double precision.
Machine precision:  15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:

    Reps Time(s) DGEFA   DGESL  OVERHEAD    KFLOPS
----------------------------------------------------
    1024   0.74  75.68%   4.05%  20.27%  2383548.023
    2048   1.48  83.11%   5.41%  11.49%  2147012.723
    4096   2.95  86.10%   2.03%  11.86%  2163528.205
    8192   5.91  82.06%   2.37%  15.57%  2254578.490
   16384  11.79  83.12%   2.63%  14.25%  2225587.867

und nochmal mir -march=native

Code: Alles auswählen

cc -O3 -march=native -o linpack linpack.c -lm

./linpack 
Enter array size (q to quit) [200]:  
Memory required:  315K.


LINPACK benchmark, Double precision.
Machine precision:  15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:

    Reps Time(s) DGEFA   DGESL  OVERHEAD    KFLOPS
----------------------------------------------------
    1024   0.82  75.61%   3.66%  20.73%  2163528.205
    2048   1.16  75.00%   3.45%  21.55%  3090754.579
    4096   2.33  79.83%   1.72%  18.45%  2960617.544
    8192   4.65  75.91%   2.80%  21.29%  3073865.209
   16384   9.31  78.09%   2.04%  19.87%  3016178.731
   32768  18.63  77.13%   2.42%  20.45%  3036530.814

Das -march=native so viel ausmacht hätte ich nicht erwartet. Auf dem RPi habe ich den Schalter -march=native auch versucht, nur hier akzeptiert der gcc es nicht.

Vielleicht kannst du den linpack Test auf dem Pogoplug auch ausführen. Letztens hatte doch jemand auch ein Beagleboard ...

Gruß
schorsch

[1] http://elinux.org/RPi_Performance

[blackm]

Hallo zusammen,

Fazit also: bei Raspian bleiben....ich bekomme bei mir auch Sicherheitsupdates.

[cirrussc]

Das -march=native so viel ausmacht hätte ich nicht erwartet.

Sicher weil ab Gcc 4.7 AVX unterstützt wird.

[schorsch_76]

Mein Test war mit gcc 4.6.3

Code: Alles auswählen

gcc --version
gcc (Gentoo 4.6.3 p1.13, pie-0.5.2) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.

Meine "Bastelinstallatation"

Unter Debian arm(el|hf) ist auch der 4.6.3er als stable markiert. [1]

Ok, mit Avx schaut das nochmal ganz anders aus:

Code: Alles auswählen

    Reps Time(s) DGEFA   DGESL  OVERHEAD    KFLOPS
----------------------------------------------------
    2048   0.91  85.71%   2.20%  12.09%  3515733.333
    4096   1.85  76.22%   3.78%  20.00%  3800792.793
    8192   3.69  79.40%   2.71%  17.89%  3712985.699
   16384   7.37  78.83%   2.31%  18.86%  3762657.748
   32768  14.77  80.50%   2.30%  17.20%  3679590.079

Nur -O3 bringt das selbe Ergebnis wie der 4.6.3er mit -O3.

[1] http://packages.debian.org/wheezy/gcc