Double gegen Integer

[J. V. (janvi)]

Momentan wundere ich mich über GCC in zwei Punkten:

1) habe ich eine Rechnung in einer Schleife von double auf int 
umgestellt. Dabei erhöht sich die Rechenzeit von 220 auf 590 mSec. 
Eigentlich hätte ich eine Beschleunigung erwartet. int, uint32_t und 
uint_fast_t sind praktisch gleich. Gibt es für die Verlangsamung eine 
plausible Erklärung oder lohnt es sich da noch mal genauer nachzuschauen 
? GCC compiliert -o3

2) bei int = double gibt es beim Compilieren keine Typwarnung. Kann man 
die überhaupt abstellen oder muß da was oberfaul sein ?

[fop (Gast)]

Gib doch mal
- die Zielhardware
- die 2...3 Programmversionen
- die Compileroptionen, insbesondere die zu Optimierung, aber auch 
Bibliotheken
- die Art der Zeitmessung
an.

Ansonsten lautet die Antwort : 42

[(prx) A. K. (prx)]

Konkretes Beispiel schlägt allgemeine Prosa.

[Amateur (Gast)]

Wie fop schon gesagt hat: Viel zu wenig Informationen.

Normalerweise sollte man davon ausgehen, dass die Integerrechnung 
schneller vonstatten geht als die mit double's, aber vielleicht muss 
dafür, an anderer Stelle, ständig von integer auf double konvertiert 
werden.

[(prx) A. K. (prx)]

Amateur schrieb:
> Normalerweise sollte man davon ausgehen, dass die Integerrechnung
> schneller vonstatten geht als die mit double's

Der Thread steht in "PC Programmierung" und bei x86 aus diesem 
Jahrtausend gilt diese Regel nicht. Da ist Fliesskommaverarbeitung sehr 
schnell und z.B. bei AMD getrennt von der Integerverarbeitung.

Der Teufel kann allerdings im Detail stecken, weshalb man dafür 
minimalisierte aber funktionsfähige Testprogramme benötigt.

[J. V. (janvi)]

Ok, es ist ein Ubuntu 18.04 LTS auf einer HP Z440 Workstation mit 8 
Kernen.
(deshalb auch unter PC Programmierung gepostet). GCC ist mit 7.4.0 schon 
etwas altbacken ist halt bei der LTS dabei und compiliert als Release 
mit -o3. Die Zeitmessung halte ich für seriös und mache ich mit dem 
Systemtimer wobei uS wegfallen und mS auf plusminus 1% reproduzierbar 
sind

auto t2 = std::chrono::high_resolution_clock::now();
    auto duration = (std::chrono::duration_cast<std::chrono::microseconds>( t2 - t1 ).count())/1000;

Die Rechnung ist eine Parallelschaltung mit vielen Iterationen:

            tmp_result = 
            (  int_lut[j] * int_lut[i] ) /
            (  int_lut[j] + int_lut[i] ); 
            tmp_result -= intTargetR;
 if( abs( tmp_result ) < (abs( best4R ) )

Die 220mS double Version sieht so aus

         tmp_result = 
            (  comb_lut[j].e_value * comb_lut[i].e_value ) /      
            (  comb_lut[j].e_value + comb_lut[i].e_value ); 
            tmp_result -= TargetR;

            if( abs( tmp_result ) < (abs( best4R ) ) )

Der if Zweig trifft selten zu und trägt damit nicht zur Laufzeit bei.
Interessanterweise wird die Laufzeit bei double ähnlich schlecht wenn 
ich die 1/R=1/Ra+1/Rb Formel nehme.

[J. V. (janvi)]

daneben hätte ich erwartet, dass ein Zugriff auf array of struct länger 
dauert als auf ein int_array aber es ist genau gleich was für einen 
guten Optimizer spricht.

struct r_data  {
                     bool        e_use;
                     std::string e_name;
                     double      e_value;
               };

std::array<r_data,MAX_COMB> comb_lut;
std::array<int_fast32_t,   MAX_COMB> int_lut;

[Sly_marbo (Gast)]

Aber die Anzahl der Iterationen ist gleich? Ich nehm mal an du hast mit 
220ms/590ms nicht nur einen Schleifendurchgang gemessen. Feste Anzahl an 
Iterationen oder gibt es eine Abbruchbedingung die bedingt durch den 
Datentp  früher oder später abbricht?

[J. V. (janvi)]

das ganze 8 mal:

>cat /proc/cpuinfo

processor  : 0
vendor_id  : GenuineIntel
cpu family  : 6
model    : 63
model name  : Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz
stepping  : 2
microcode  : 0x43
cpu MHz    : 1197.228
cache size  : 10240 KB
physical id  : 0
siblings  : 8
core id    : 0
cpu cores  : 4
apicid    : 0
initial apicid  : 0
fpu    : yes
fpu_exception  : yes
cpuid level  : 15
wp    : yes
flags    : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx 
pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl 
xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor 
ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 
sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand 
lahf_lm abm cpuid_fault epb invpcid_single pti intel_ppin ssbd ibrs ibpb 
stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust 
bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc 
dtherm ida arat pln pts md_clear flush_l1d
bugs    : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs itlb_multihit
bogomips  : 6983.82
clflush size  : 64
cache_alignment  : 64
address sizes  : 46 bits physical, 48 bits virtual
power management:

processor  : 1
vendor_id  : GenuineIntel
cpu family  : 6
model    : 63
model name  : Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz
stepping  : 2
microcode  : 0x43
cpu MHz    : 1197.264
cache size  : 10240 KB
physical id  : 0
siblings  : 8
core id    : 1
cpu cores  : 4
apicid    : 2
initial apicid  : 2
fpu    : yes
fpu_exception  : yes
cpuid level  : 15
wp    : yes
flags    : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx 
pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl 
xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor 
ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 
sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand 
lahf_lm abm cpuid_fault epb invpcid_single pti intel_ppin ssbd ibrs ibpb 
stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust 
bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc 
dtherm ida arat pln pts md_clear flush_l1d
bugs    : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs itlb_multihit
bogomips  : 6983.82
clflush size  : 64
cache_alignment  : 64
address sizes  : 46 bits physical, 48 bits virtual

[Pandur S. (jetztnicht)]

Fliesskomma Rechnung ist in einer FPU schon sehr schnell, aber eben 
keine Integergeschwindigkeit. Da fehlt schon noch ein Stueck.
Vielleicht nicht ganz unwichtig... Eine gleich grosse Integer Zahl hat 
eine hoehere Genauigkeit wie eine Floatzahl.

[J. V. (janvi)]

es sind in beiden Fälle etwa 26 Mio Iterationen mit einer herkömmlichen 
verschachtelten for Śchleife (index i,j), keine range based loop.

[ergo70 (Gast)]

Was macht der denn da für Instruktionen draus? Vielleicht wird der 
double Code irgendwie autovektorisiert oder sowas.

Hier kann man sowas austesten:

https://godbolt.org/

[J. V. (janvi)]

Danke für das hübsche Spielzeug. Damit brauch ich nicht an cmake 
rumbasteln. Ich muss mir noch etwas Zeit nehmen das ganze weiter zu 
isolieren. Wenn ich zwischen den Zeilen lese sollte sich eine nähere 
Betrachtung doch lohnen da auch andere hier erwarten daß int schneller 
als double sein sollte.

[Oliver S. (oliverso)]

J. V. schrieb:
> Danke für das hübsche Spielzeug.

Ganz ehrlich: Wer Mikro-Optimierungen betrieben will, und über 
cache-misses schwadroniert, sollte in der Lage sein, seiner Toolchain 
Disassemblies zu entlocken, und die auch zu verstehen.

Oliver

[Dennis H. (c-logic)]

macht gcc/cc von sich aus Gebrauch von AVX/SSEx ?
Ich würde gern mal das Compilat des Schnipsels sehen von beiden 
Versionen.

So ein Gedanke: Fliesskomma Richtung SSE auslagern und Integer auf dem 
Standardbefehlssatz.

[Oliver S. (oliverso)]

Dennis H. schrieb:
> macht gcc/cc von sich aus Gebrauch von AVX/SSEx ?

Muss er halt nachschauen, wie sein gcc configuriert ist. Üblicherweise 
erstellt der generischen (ARM64)-Code.

Wer aber auf dem level optimiert, soellte -march=native und vielleicht 
auch noh ein paar weitere Optionen nutzen.

Oliver

[Dennis H. (c-logic)]

J.V.:

Haste schonmal auf so einer Seite geschaut ?

https://docs.microsoft.com/de-de/cpp/intrinsics/x64-amd64-intrinsics-list?view=vs-2019

Da kann man noch einiges Rauskitzeln mit direkten SSE-Befehlen in C.
Erfreulicherweise gibt es dann Datentypen die das Handhaben 
vereinfachen.

In der Liste fehlen jetzt leider die AVX512-Befehle.

Ich habe das mal mit Anwendung auf ein Numpy-Array genutzt. Das 
Numpy-Eigene OR war mir zu langsam. Mit

  __m256i* pnt=PyArray_DATA(in_array);
  __m256i q0,q1,q2,q3;

  uint64_t t=PyArray_SIZE(in_array)/16/4/2;
  while(t--) {
    q0=*pnt;
    q1=*(pnt+1);
    q2=*(pnt+2);
    q3=*(pnt+3);
    *pnt++=_mm256_or_si256(q0,p);
    *pnt++=_mm256_or_si256(q1,p);
    *pnt++=_mm256_or_si256(q2,p);
    *pnt++=_mm256_or_si256(q3,p);
  }

gings direkt 4x so schnell.

[Le X. (lex_91)]

Oliver S. schrieb:
> Wer aber auf dem level optimiert, soellte -march=native und vielleicht
> auch noh ein paar weitere Optionen nutzen.

Oliver S. schrieb:
> Ganz ehrlich: Wer Mikro-Optimierungen betrieben will, und über
> cache-misses schwadroniert,

Halt mal etwas den Ball flach.

Ich habe eher das Gefühl der TE interessiert sich einfach dafür was da 
genau los ist.
Er ist zufällig über eine Merkwürdigkeit gestolpert und will das nun 
genauer untersuchen.
Und auch die Mitleser (inklusive mir) scheinen das interessant zu finden 
weil das beobachtete Verhalten erstmal ungewöhnlich scheint.

Von einem zwingenden (Mikro-) Optimierungsbedarf lese ich da nichts.

[Oliver S. (oliverso)]

Der TO ist ja nicht nur in dem Thread hier unterwegs...

Oliver

[Manfred M. (bittbeisser)]

Mein erster Verdächtiger wäre die Division.

Übersetze das Programm mal mit den Optionen -g -S und schau dir mal den
Assembler Output an. Durch die -g Option ist im Assemblertext auch die 
ursprüngliche Zeilennummer enthalten, wonach du suchen kannst.

[(prx) A. K. (prx)]

Joggel E. schrieb:
> Fliesskomma Rechnung ist in einer FPU schon sehr schnell, aber eben
> keine Integergeschwindigkeit.

Die Fliesskomma-Division ist heute wesentlich schneller als die 
Integer-Division (seit Intel Core 2 und AMD K7).

CPU ist Haswell, dafür gilt lt. Agner Fog als Latenz:
- Integer Division u32:  22-29 Takte
- SSE Fliesskomma 32/64: 10-13 Takte
Beim Durchsatz sind es 9-11 vs 7 Takte. Das ist der Wert, nach dem die 
nächste unabhängige Division gestartet werden kann.

[JV (Gast)]

CPU ist Haswell, dafür gilt lt. Agner Fog als Latenz:
- Integer Division u32:  22-29 Takte
- SSE Fliesskomma 32/64: 10-13 Takte

Knapp Faktor 3 könnte sogar passen. Die Laufzeit verlängert sich von 
220mSec auf 580 mSec und das ist nicht von Pappe und hat wohl auch nix 
mit Mikrooptimierung zu tun. (Ein Mix-Listing habe ich leider noch immer 
nicht gekriegt)

[John Doe (Gast)]

J. V. schrieb:
> Ok, es ist ein Ubuntu 18.04 LTS auf einer HP Z440 Workstation mit 8
> Kernen.
> (deshalb auch unter PC Programmierung gepostet). GCC ist mit 7.4.0 schon
> etwas altbacken ist halt bei der LTS dabei

Mach mal das Ubuntu nicht schlechter als es ist:
gcc in Version 8.3 ist auch bei der 18.04 LTS als Paket zu haben.

[JV (Gast)]

hier mal die Integer Version

402:/home/jv/kicad/pcb_calculator/eseries.cpp ****             tmp_result = 
 403:/home/jv/kicad/pcb_calculator/eseries.cpp ****             (  int_lut[j] * int_lut[i] ) /      
 5980                           .loc 17 403 0
 5981 09c0 480FAFC3             imulq   %rbx, %rax
 402:/home/jv/kicad/pcb_calculator/eseries.cpp ****             (  int_lut[j] * int_lut[i] ) /      
 5982                           .loc 17 402 0
 5983 09c4 4899                 cqto
 5984 09c6 48F7FF               idivq   %rdi
 5985                   .LVL555:
 404:/home/jv/kicad/pcb_calculator/eseries.cpp ****             (  int_lut[j] + int_lut[i] );      // calculate 2R|2R parallel
 405:/home/jv/kicad/pcb_calculator/eseries.cpp ****             tmp_result -= intTargetR;                                   // calculate 4R deviation
 5986                           .loc 17 405 0
 5987 09c9 482B4424             subq    8(%rsp), %rax
 5987      08
 5988                   .LVL556:
 5989                   .LBB7424:
 5990                   .LBB7425:
 5991                   .LBB7426:
  56:/usr/include/c++/7/bits/std_abs.h **** #endif
 5992                           .loc 32 56 0
 5993 09ce 4889C2               movq    %rax, %rdx
 5994                   .LBE7426:
 5995                   .LBE7425:
 5996                   .LBE7424:
 5997                           .loc 17 405 0
 5998 09d1 4889C3               movq    %rax, %rbx
 5999                   .LVL557:
 6000                   .LBB7567:
 6001                   .LBB7428:
 6002                   .LBB7427:
  56:/usr/include/c++/7/bits/std_abs.h **** #endif
 6003                           .loc 32 56 0
 6004 09d4 48C1FA3F             sarq    $63, %rdx
 6005 09d8 4889D0               movq    %rdx, %rax
 6006                   .LVL558:
 6007 09db 4831D8               xorq    %rbx, %rax
 6008 09de 4829D0               subq    %rdx, %rax
 6009                   .LBE7427:
 6010                   .LBE7428:
 406:/home/jv/kicad/pcb_calculator/eseries.cpp **** 
 407:/home/jv/kicad/pcb_calculator/eseries.cpp ****             if( abs( tmp_result ) < (abs( best4R ) ) )                      // if new 4R is better
 6011                           .loc 17 407 0
 6012 09e1 4839C8               cmpq    %rcx, %rax
 6013 09e4 0F8CE601             jl      .L492
 6013      0000
 6014                   .LVL559:
 6015 09ea 4983C508             addq    $8, %r13
 6016 09ee 4883C530             addq    $48, %rbp
 6017                   .LBE7567:
 6018                   .LBE7579:
 382:/home/jv/kicad/pcb_calculator/eseries.cpp ****         {
 6019                           .loc 17 382 0 discriminator 2
 6020 09f2 48396C24             cmpq    %rbp, 40(%rsp)
 6020      28
 6021 09f7 0F845903             je      .L493
 6021      0000

[JV (Gast)]

und hier die float Version

402:/home/jv/kicad/pcb_calculator/eseries.cpp ****             tmp_result = 
 403:/home/jv/kicad/pcb_calculator/eseries.cpp ****             (  int_lut[j] * int_lut[i] ) /      
 5980                           .loc 17 403 0
 5981 09c0 480FAFC3             imulq   %rbx, %rax
 402:/home/jv/kicad/pcb_calculator/eseries.cpp ****             (  int_lut[j] * int_lut[i] ) /      
 5982                           .loc 17 402 0
 5983 09c4 4899                 cqto
 5984 09c6 48F7FF               idivq   %rdi
 5985                   .LVL555:
 404:/home/jv/kicad/pcb_calculator/eseries.cpp ****             (  int_lut[j] + int_lut[i] );      // calculate 2R|2R parallel
 405:/home/jv/kicad/pcb_calculator/eseries.cpp ****             tmp_result -= intTargetR;                                   // calculate 4R deviation
 5986                           .loc 17 405 0
 5987 09c9 482B4424             subq    8(%rsp), %rax
 5987      08
 5988                   .LVL556:
 5989                   .LBB7424:
 5990                   .LBB7425:
 5991                   .LBB7426:
  56:/usr/include/c++/7/bits/std_abs.h **** #endif
 5992                           .loc 32 56 0
 5993 09ce 4889C2               movq    %rax, %rdx
 5994                   .LBE7426:
 5995                   .LBE7425:
 5996                   .LBE7424:
 5997                           .loc 17 405 0
 5998 09d1 4889C3               movq    %rax, %rbx
 5999                   .LVL557:
 6000                   .LBB7567:
 6001                   .LBB7428:
 6002                   .LBB7427:
  56:/usr/include/c++/7/bits/std_abs.h **** #endif
 6003                           .loc 32 56 0
 6004 09d4 48C1FA3F             sarq    $63, %rdx
 6005 09d8 4889D0               movq    %rdx, %rax
 6006                   .LVL558:
 6007 09db 4831D8               xorq    %rbx, %rax
 6008 09de 4829D0               subq    %rdx, %rax
 6009                   .LBE7427:
 6010                   .LBE7428:
 406:/home/jv/kicad/pcb_calculator/eseries.cpp **** 
 407:/home/jv/kicad/pcb_calculator/eseries.cpp ****             if( abs( tmp_result ) < (abs( best4R ) ) )                      // if new 4R is better
 6011                           .loc 17 407 0
 6012 09e1 4839C8               cmpq    %rcx, %rax
 6013 09e4 0F8CE601             jl      .L492
 6013      0000
 6014                   .LVL559:
 6015 09ea 4983C508             addq    $8, %r13
 6016 09ee 4883C530             addq    $48, %rbp
 6017                   .LBE7567:
 6018                   .LBE7579:
 382:/home/jv/kicad/pcb_calculator/eseries.cpp ****         {
 6019                           .loc 17 382 0 discriminator 2
 6020 09f2 48396C24             cmpq    %rbp, 40(%rsp)
 6020      28
 6021 09f7 0F845903             je      .L493

[JV (Gast)]

Float ist beim Kopieren über die Zwischenablage falsch gelaufen
Hier also nochmal
[c]
 399:/home/jv/kicad/pcb_calculator/eseries.cpp **** 
tmp_result =
 400:/home/jv/kicad/pcb_calculator/eseries.cpp ****             ( 
comb_lut[j].e_value * comb_lut[i].e_value ) /
 6235                           .loc 17 400 0
 6236 0a40 F20F59C2             mulsd   %xmm2, %xmm0
 399:/home/jv/kicad/pcb_calculator/eseries.cpp ****             ( 
comb_lut[j].e_value * comb_lut[i].e_value ) /
 6237                           .loc 17 399 0
 6238 0a44 F20F5EC4             divsd   %xmm4, %xmm0
 6239                   .LVL584:
 401:/home/jv/kicad/pcb_calculator/eseries.cpp ****             ( 
comb_lut[j].e_value + comb_lut[i].e_value );      // calculate 2R|2R 
parallel
 402:/home/jv/kicad/pcb_calculator/eseries.cpp **** 
tmp_result -= targetR;                                      // calculate 
4R deviation
 6240                           .loc 17 402 0
 6241 0a48 F20F5CC3             subsd   %xmm3, %xmm0
 6242                   .LVL585:
 6243                   .LBB8220:
 6244                   .LBB8221:
 6245                   .LBB8222:
 6246                           .loc 32 71 0
 6247 0a4c 660F28D0             movapd  %xmm0, %xmm2
 6248 0a50 660F5415             andpd   .LC9(%rip), %xmm2
 6248      00000000
 6249                   .LBE8222:
 6250                   .LBE8221:
 403:/home/jv/kicad/pcb_calculator/eseries.cpp ****
 404:/home/jv/kicad/pcb_calculator/eseries.cpp ****             if( abs( 
tmp_result ) < abs( rslt_lut[S4R].e_value ) )      // if new 4R is 
better
 6251                           .loc 17 404 0
 6252 0a58 660F2ECA             ucomisd %xmm2, %xmm1
 6253 0a5c 0F87DE01             ja      .L513
 6253      0000
 6254                   .LVL586:
 6255                   .L471:
 6256 0a62 4883C330             addq    $48, %rbx
 6257                   .LBE8220:
 6258                   .LBE8365:
 380:/home/jv/kicad/pcb_calculator/eseries.cpp ****         {
 6259                           .loc 17 380 0 discriminator 2
 6260 0a66 483B5C24             cmpq    8(%rsp), %rbx
 6260      08
 6261 0a6b 0F843F03             je      .L514
 6261      0000
 6262                   .L479:
 6263                   .LBB8366:
 382:/home/jv/kicad/pcb_calculator/eseries.cpp **** 
tmp_result -= targetR;                                     // calculate 
4R deviation
 6264                           .loc 17 382 0
 6265 0a71 F20F1053             movsd   32(%rbx), %xmm2

[J. V. (janvi)]

Kann leider nicht mehr editieren da ich über timeout ausgeloggt wurde.

Die Codeunterschiede sehen gar nicht soo arg aus alsda wären

mulsd und divsd für die double Version und
imulq und idivq für die interger Version

[(prx) A. K. (prx)]

Das ist die 64-Bit Integer Version mit Vorzeichen. Die ist noch 
langsamer.
Latenz:
- Integer Division s64: 39-103 Takte
- SSE Fliesskomma 32/64: 10-13 Takte
Durchsatz:
- Integer Division s64:  24-81 Takte
- SSE Fliesskomma 32/64:     7 Takte

Gegenüber dem Haswell ist bei Integers sogar der Goldmont (Atom) in 
meinem Netbook schneller (s64: 13-43, double: 34).

Also Leute, von der Idee das bei den grossen x86 Integers schneller als 
Doubles seien, bitte ganz schnell abschwören. Nur bei den kleinen 
stimmts. ;-)

[cppbert (Gast)]

J. V. schrieb:
> daneben hätte ich erwartet, dass ein Zugriff auf array of struct
> länger
> dauert als auf ein int_array aber es ist genau gleich was für einen
> guten Optimizer spricht.
> struct r_data  {
>                      bool        e_use;
>                      std::string e_name;
>                      double      e_value;
>                };
>
> std::array<r_data,MAX_COMB> comb_lut;
> std::array<int_fast32_t,   MAX_COMB> int_lut;

Keine Ahnung wo dein Wissen her kommt - nach Gefühl fühlt es sich an als 
wuerdest du 286/386 Erfahrungen auf aktuelle Hardware spiegeln, die 
meisten deiner Vermutungen (auch in anderen Posts) sind schlicht und 
einfach falsch, sorry

Deine Zeitmessung ist viel zu ungenau um diesen Unterschied zu erkennen, 
selbst wenn es einen geben würde

[cppbert (Gast)]

Schau doch einfach auf den assemblercode, der Optimizer hatte da nur 
1982 probleme mit - deswegen finde ich deine Aussagen so verwirrent

[JV (Gast)]

> Keine Ahnung wo dein Wissen her kommt

Habs ja eingesehen. Beim Anschauen von /proc/cpuinfo ist klar geworden 
daß bei den Cachegrößen sowieso die gesamte LUT reinpasst. Egal ob mit 
oder ohne struct. Ebenso habe ich mich halt auch mit den floats 
verpeilt. Auch wenn ich hier die Hocke vollkriege, war ich zumindest 
nicht der Einzige der danebengeschätzt hat.