Archiv verlassen und diese Seite im Standarddesign anzeigen : 128bit "long double".
Ganon
2005-05-10, 20:28:15
Hi.
Ich bin gerade etwas "verwirrt".
Damals in OS X Panther (gcc 3.3), kam bei Verwendung vom C-Datentyp "long double" immer eine Warnung.
"WARNING.... .... the size may change in future release ...."
"long double" ist dort 64bit groß. Also nicht größer als ein "double".
Jetzt habe ich OS X Tiger (gcc 4.0) und musste, mit erstaunen, feststellen, das "long double" jetzt 128bit groß ist.
Würde mich aber wundern, wenn ein G4 eine 128bit FPU hat. ;)
Deswegen wollte ich mal fragen wie so etwas zu Stande kommt!?! Ist das nicht "etwas" overkill für ne FPU?
Danke. :)
Aqualon
2005-05-10, 20:42:16
Werden die long double vielleicht durch die Altivec-Einheit berechnet? Das würde die 128Bit beim G4 erklären. Theoretisch könnte man den long double auch auf 2 64Bit double splitten, was aber nicht sonderlich schnell sein dürfte. Wie wärs mal mit nem kleinen Test, ob long double merklich langsamer ist als double?
Aqua
Alle modernen x86 Chips haben eine 80-Bit FPU. Je nach Compiler ist long double im Speicher dann 64, 96 oder 128 Bit groß.
Bei 64-Bit werden nützliche Daten weggeworfen, bei 96 oder 128 Bit wird mehr Speicher belegt um die Daten schneller laden zu können (alignment/padding).
Ganon
2005-05-10, 20:57:25
@Trap
Nunja. Ich hab aber kein x86. ;) Aber das klingt logisch. Nur haben G4, glaube ich, nur eine 64bit-FPU und keine 80bit-FPU.
@Aqualon
Hmm. Wie bencht man sowas am besten? Hat jemand vielleicht mal fix ein ANSI-C(++)-Quellcode?
Gibt es unter OS X den "time"-Befehl? Dann nimm http://shootout.alioth.debian.org/benchmark.php?test=harmonic&lang=gcc&id=0&sort=fullcpu und time mal :)
Je nach Compiler ist long double im Speicher dann 64, 96 oder 128 Bit groß.
Bei 64-Bit werden nützliche Daten weggeworfen, bei 96 oder 128 Bit wird mehr Speicher belegt um die Daten schneller laden zu können (alignment/padding).Das ist Quark. sizeof(long double) hat nix mit dem Alignment zu tun.
Altivec kann auch nur 32bit floats. Das ganze ist also äußerst komisch.
Ich hab leider keinen PowerPC zur Verfügung sonst würde ich mal das Assemblat anschauen ;)
Long double
In previous releases of GCC, the long double type was just a synonym for double. GCC 4.0 now supports true long double. In GCC 4.0 long double is made up of two double parts, arranged so that the number of bits of precision is approximately twice that of double.
Warning: In versions of Mac OS X prior to 10.3.9 the system C library did not support true long double, so if you try to pass a long double value to any system C library routine, your program may not run on older systems or may not produce the expected results.Ich wundere mich grad nur wie das funktionieren soll :|
Ganon
2005-05-10, 22:05:23
Ja, ne, ähm, es ist, naja... LANGSAM!
Double:
time ./harmonic.gcc_run 123456789
19.208617435
real 0m5.353s
user 0m5.337s
sys 0m0.014s
Long Double:
time ./harmonic.gcc_run 123456789
19.208617435
real 0m33.683s
user 0m33.622s
sys 0m0.057s
@Coda
Sag mir was ich machen soll, dann poste ich es. ;)
Ganon
2005-05-10, 22:12:02
int main()
{
long double a;
a = 1.1;
}
ergibt
.section __TEXT,__text,regular,pure_instructions
.section __TEXT,__picsymbolstub1,symbol_stubs,pure_instructions,32
.machine ppc
.const
.align 4
LC0:
.long 1072798105
.long -1717986918
.long 0
.long 0
.text
.align 2
.globl _main
_main:
stmw r30,-8(r1)
stwu r1,-80(r1)
mr r30,r1
mflr r0
bcl 20,31,"L00000000001$pb"
"L00000000001$pb":
mflr r10
mtlr r0
addis r2,r10,ha16(LC0-"L00000000001$pb")
la r2,lo16(LC0-"L00000000001$pb")(r2)
lfd f0,0(r2)
lfd f1,8(r2)
addi r2,r30,32
stfd f0,0(r2)
stfd f1,8(r2)
lwz r1,0(r1)
lmw r30,-8(r1)
blr
.subsections_via_symbols
Das ist Quark. sizeof(long double) hat nix mit dem Alignment zu tun.
Natürlich hat es das (auf x86-kompatiblen Systemen).
-m96bit-long-double
-m128bit-long-double
These switches control the size of long double type. The i386 application binary interface specifies the size to be 96 bits, so -m96bit-long-double is the default in 32 bit mode.
Modern architectures (Pentium and newer) would prefer long double to be aligned to an 8 or 16 byte boundary. In arrays or structures conforming to the ABI, this would not be possible. So specifying a -m128bit-long-double will align long double to a 16 byte boundary by padding the long double with an additional 32 bit zero.
In the x86-64 compiler, -m128bit-long-double is the default choice as its ABI specifies that long double is to be aligned on 16 byte boundary.
Notice that neither of these options enable any extra precision over the x87 standard of 80 bits for a long double.
These switches control the size of long double type.
Dass daraus ein anderes Alignment resultiert ist ja nur ein indirekter Effekt.
Es geht wohl nur darum, dass irgendwo definiert wurde, dass man die 80bit TEMPREALS wenn man sie denn wirklich speichert mit 96bit Alignment macht. Das ist aber ineffizient, deshalb gibt es auch die Option mit 128bit.
64bit wäre die beste Lösung, aber irgendwie muss long double größer sein, auch wenn's nix bringt. Was ein Quatsch.
micki
2005-05-11, 10:58:05
Das ist Quark. ...nix mit dem Alignment zu tun.
hat es schon, denn ansonsten müßte long double 80bit sein und würde mit in nem array mit nem 10byte allignment im speicher indizieren... ;)
64bit wäre die beste Lösung, aber irgendwie muss long double größer sein, auch wenn's nix bringt. Was ein Quatsch.
Aber sicher bringt es was. Die FPU rechnet mit 80 bit, die sollte man auch irgendwie in den Speicher laden können. Mit 64 bit long doubles geht das nicht.
Ja ok, irgendwie haben wir beide Recht. Weil normal gibt es ja kein Padding bei elementaren Datentypen.
zeckensack
2005-05-13, 11:57:53
Hi.
Ich bin gerade etwas "verwirrt".
Damals in OS X Panther (gcc 3.3), kam bei Verwendung vom C-Datentyp "long double" immer eine Warnung.
"WARNING.... .... the size may change in future release ...."
"long double" ist dort 64bit groß. Also nicht größer als ein "double".
Jetzt habe ich OS X Tiger (gcc 4.0) und musste, mit erstaunen, feststellen, das "long double" jetzt 128bit groß ist.
Würde mich aber wundern, wenn ein G4 eine 128bit FPU hat. ;)
Deswegen wollte ich mal fragen wie so etwas zu Stande kommt!?! Ist das nicht "etwas" overkill für ne FPU?
Danke. :)1)Warum benutzt du überhaupt long double, wenn du eigentlich erwartest dass es sowieso nur 64 Bit sind? :|
2)Vermutlich haben die GCC-Menschen dir einfach eine "Emulation" von 128 Bit FP geschenkt, um mit den 80 Bit aus der x86-Welt präzisionstechnisch zumindest gleichzuziehen, und somit die Portabilität x86=>PPC zu erhöhen.
Wenn du das nicht brauchst, siehe 1. Wenn doch, dann freu dich darüber dass du es nicht selbst implementieren musstest. Das ist nämlich wirklich Arbeit.
Ganon
2005-05-13, 13:46:12
1)Warum benutzt du überhaupt long double, wenn du eigentlich erwartest dass es sowieso nur 64 Bit sind? :|
2)Vermutlich haben die GCC-Menschen dir einfach eine "Emulation" von 128 Bit FP geschenkt, um mit den 80 Bit aus der x86-Welt präzisionstechnisch zumindest gleichzuziehen, und somit die Portabilität x86=>PPC zu erhöhen.
Wenn du das nicht brauchst, siehe 1. Wenn doch, dann freu dich darüber dass du es nicht selbst implementieren musstest. Das ist nämlich wirklich Arbeit.
1) Es war eher allgemein gemeint. Denn wenn ich z.B. einen Fraktal-Generator unter Panther kompiliert habe, kam immer die Meldung das sich die Größe später ändern könnte.
Als ich es unter Tiger kompiliert habe, kam die Meldung nicht mehr und da habe ich fix mal nachgeguckt wie groß es jetzt ist. War halt nur so "erstaunt", da ich 128bit nicht erwartet habe. Da wollte ich halt wissen wie sich das verhält.
Das wurde ja jetzt geklärt. :)
2.) Auch möglich.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.