Du mischst warscheinlich 32bit und 64bit-Bibliotheken, vielleicht haben die Dinger noch den selben Namen. Dann wird sich der Rechner ordentlich verschlucken ...
Ich habe möglichst die 32bit-binary bevorzugt, weil:
http://projects.blender.org/pipermail/bf-committers/2006-March/013816.html
Darum wollte ich eben auch mit der chroot-Umgebung anfangen.
Kannst ja mal deine Ergebnisse auf eine Webseite laden und den Link hier posten, würde ich mir schon gern mal ansehen.
Meine Webseite ist gerade tot. Hab irgendwann mal auf den falschen Knopf gerdückt. Im Moment seh ich gar kein Land das überhaupt zu schaffen.
Ich bin jetzt gerade an Gelato dran. Soll extrem fix sein. Interessantes script: http://forums.nvidia.com/index.php?s=995153ef2dd83062d0b6d696b07ad18c&sh...
Jetzt findet Gentoo Gelato nicht. Manchmal kanns schon nerven!
MfG Willi
Am Montag, den 30.04.2007, 08:43 +0200 schrieb willi_wotte@woelunds.de:
Hallo,
Ich habe möglichst die 32bit-binary bevorzugt, weil:
64bit macht meines Wissens nur wirklich Sinn, wenn man mehr als 4GByte Arbeitsspeicher addressieren will.
Strick doch alles auf 32bit um, das ist bestimmt Stressfreier. Oder du kannst die Bibiotheken auf 64bit portieren.
Viel Spass, und die Bilder möchte ich gern mal sehen. Jan
Jan Rakelmann schrieb:
Am Montag, den 30.04.2007, 08:43 +0200 schrieb willi_wotte@woelunds.de:
Ich habe möglichst die 32bit-binary bevorzugt, weil:
64bit macht meines Wissens nur wirklich Sinn, wenn man mehr als 4GByte Arbeitsspeicher addressieren will.
Oder bei doppeltgenauer Fließkomma-Berechnung (Faktor drei bis vier). Bei Stringoperationen würde ich auch erwarten, dass 64bit u.U. schneller sein könnte.
Tobias.
Am Mittwoch, den 02.05.2007, 09:25 +0200 schrieb Tobias Schlemmer:
Tobias,
Oder bei doppeltgenauer Fließkomma-Berechnung (Faktor drei bis vier). Bei Stringoperationen würde ich auch erwarten, dass 64bit u.U. schneller sein könnte.
Ich würde mal denke, doppelte Fließkomma-Rechnung spielt in der Computergrafik keine Rolle. Da fällt es nicht auf wenn mal ein halbes Pixel daneben geht. In F95 ist sogar vierfache Genauigkeit drin. Beim gfortran ist es glaube ich Kind = 12. Die Kind-Parameterwerte sind dummerweise Kompilerabhängig. Sollte man auch mal ändern.
Das Dumme an der Geschichte ist nur, die rechenintensiven Programme, also Mathematica und Maple und so ein Kram werden in C, also der eigentliche Rechenkern, geschrieben und nutzen den ganzen Kram nicht.
Und selbst die Numeriker knötern mit Matlab rum, und finden das toll.
Eigentlich müßte um jede Rechenoperation ein Exeptionhandling gemacht werden um zu prüfen, liege ich noch im Intervall oder bin ich im digitalen Nirvana.
Achso, damit jetzt niemand sich diskriminiert fühlt. ;-) In C würde es warscheinlich long long double heißen.
Ich bin zuhause auch mit 64bit unterwegs, allerdings nur damit ich zur Uni kompatibel bin, und nicht jedesmal die die Kind-parameter ändern muss. Den Geschwindigkeitsgewinn habe ich nur von 2 mal Celeron a 466 MHz ( fühlbar als ca. 700 Mhz ) auf 2,8 Ghz gespürt. In den ersten drei Tagen hatte ich Probleme der Maus zu folgen. ;-)
Ein ordentlicher Level-1-Cache würde da bestimmt auch helfen. Nicht wie bei mir, ein Ferarri ohne Motor.
Einen kleinen Schub gab es noch mal bei der Umstellung von UDMA133 auf SATA.
Viele Grüße Jan
PS: jetzt ärger ich mich den alten Celeron weggeben zu haben, könnte eine Serverknecht gebrauchen. ;-)
Jan Rakelmann schrieb:
Am Mittwoch, den 02.05.2007, 09:25 +0200 schrieb Tobias Schlemmer:
Tobias,
Oder bei doppeltgenauer Fließkomma-Berechnung (Faktor drei bis vier). Bei Stringoperationen würde ich auch erwarten, dass 64bit u.U. schneller sein könnte.
Ich würde mal denke, doppelte Fließkomma-Rechnung spielt in der Computergrafik keine Rolle. Da fällt es nicht auf wenn mal ein halbes Pixel daneben geht. In F95 ist sogar vierfache Genauigkeit drin. Beim gfortran ist es glaube ich Kind = 12.
10 oder 16 je nach Prozessor-Architektur.
Die Kind-Parameterwerte sind dummerweise Kompilerabhängig. Sollte man auch mal ändern.
Geht nicht, von wegen dreiwertigen bits usw.
Das Dumme an der Geschichte ist nur, die rechenintensiven Programme, also Mathematica und Maple und so ein Kram werden in C, also der eigentliche Rechenkern, geschrieben und nutzen den ganzen Kram nicht.
Mathematika und Maple sind Computer-Algebra-Systeme und die sind definitiv eher von Datenstrukturen abhängig, was in Fortran ziemlich grausam wäre.
Und selbst die Numeriker knötern mit Matlab rum, und finden das toll.
Klar, weils schnell zu programmieren ist. Der Kern könnte aber Fortran sein.
Eigentlich müßte um jede Rechenoperation ein Exeptionhandling gemacht werden um zu prüfen, liege ich noch im Intervall oder bin ich im digitalen Nirvana.
Na ja, es gibt noch +Infinity, -Infinity und NaN.
Achso, damit jetzt niemand sich diskriminiert fühlt. ;-) In C würde es warscheinlich long long double heißen.
Du meinst „long double“ und das gibt es schon. Gabs in gcc übrigens schon lange bevor es in gfortran war.
Ich bin zuhause auch mit 64bit unterwegs, allerdings nur damit ich zur Uni kompatibel bin, und nicht jedesmal die die Kind-parameter ändern muss.
Was schreibst Du denn für komische Programme? Mit F95 kannst Du kinds hardwareunabhängig definieren.
Tobias
Am Donnerstag, den 03.05.2007, 09:05 +0200 schrieb Tobias Schlemmer:
Geht nicht, von wegen dreiwertigen bits usw.
Kannst du das mal etwas ausführlicher erklären, bitte?
Mathematica und Maple sind Computer-Algebra-Systeme und die sind definitiv eher von Datenstrukturen abhängig, was in Fortran ziemlich grausam wäre.
Ich habe den Kaplan, Computeralgebra hier. Der Maple-Kern ist in C geschrieben, nicht einsehbar, der Rest dann in der Maple-Sprache. Mathematica soll komplett in C geschrieben sein.
Was schreibst Du denn für komische Programme? Mit F95 kannst Du kinds hardwareunabhängig definieren.
Jetzt hat es sich verbessert ;-), aber angefangen habe ich mit dem Salford und mich immer geärgert, das vieles nicht ging was Prof. Walter auf den FTP-Server gelegt hat. Mit dem gfortran geht aber alles.
Jan
Jan Rakelmann schrieb:
Am Donnerstag, den 03.05.2007, 09:05 +0200 schrieb Tobias Schlemmer:
Geht nicht, von wegen dreiwertigen bits usw.
Kannst du das mal etwas ausführlicher erklären, bitte?
Bei derartigen Diskussionen wird häufig eine Architektur angeführt, wo ein Bit drei Werte haben kann. Dann haben 8 Bit einen Zahlenbereich von 3^8 und nicht von 2^8. Hab selber aber noch nie an so einer Maschine gesessen.
Mathematica und Maple sind Computer-Algebra-Systeme und die sind definitiv eher von Datenstrukturen abhängig, was in Fortran ziemlich grausam wäre.
Ich habe den Kaplan, Computeralgebra hier. Der Maple-Kern ist in C geschrieben, nicht einsehbar, der Rest dann in der Maple-Sprache. Mathematica soll komplett in C geschrieben sein.
Wie gesagt, ich würde es nicht anders machen (C++ vielleicht, Ada kenne ich nicht).
Tobias
Am 03.05.2007 um 09:05 schrieb Tobias Schlemmer:
Ich würde mal denke, doppelte Fließkomma-Rechnung spielt in der Computergrafik keine Rolle. Da fällt es nicht auf wenn mal ein halbes Pixel daneben geht. In F95 ist sogar vierfache Genauigkeit drin. Beim gfortran ist es glaube ich Kind = 12.
10 oder 16 je nach Prozessor-Architektur.
Falsch, kann man definieren wie man will. 686er CPUs stellen 80bit-FP- Register zur Verfügung (KIND=10). "double double"/"quad" (KIND=16) gibts auch, ist aber blöd von Hand zu programmieren. Deswegen verstecken die Fortran-Compiler es hinter den KIND-Parametern. Du kannst Dir mit SELECTED_REAL_KIND selbst Genauigkeitsbereiche definieren, ohne die unterliegende Hardware zu kennen, was Sinn und Zweck der Übung ist. (gfortran tut (tat?) das mit libmpfr und libgmp.) Z.B.: REAL(KIND=8) :: x ! double REAL(KIND=SELECTED_REAL_KIND(100,50)) :: y ! 100 Dezimal(!)-Stellen Genauigkeit im Exponentenbereich 10^(-50) bis 10^50
Die Kind-Parameterwerte sind dummerweise Kompilerabhängig.
Sind sie nicht, deren Funktionsweise ist im Standard definiert. Manche Compiler unterstützen manche KINDs nicht, s.o.
Eigentlich müßte um jede Rechenoperation ein Exeptionhandling gemacht werden um zu prüfen, liege ich noch im Intervall oder bin ich im digitalen Nirvana.
Na ja, es gibt noch +Infinity, -Infinity und NaN.
Und genau dafür kannst Du definieren, ob die FPU beim Auftreten eines solchen Wertes eine "Floating Point Exception" auslöst, und einen definierten "Exception Handler" ausführt. Diese Checks sind aber so teuer (zeitintensiv) und so umstritten (mehr Genauigkeit -- Bitstellen, s.o. -- langt meistens, oder ne Weiterbildung der Programmierer zur Vermeidung "klassischer Fehler"), daß sie kaum benutzt werden.
MfG Sebastian
Sebastian Hegler schrieb:
Am 03.05.2007 um 09:05 schrieb Tobias Schlemmer:
Ich würde mal denke, doppelte Fließkomma-Rechnung spielt in der Computergrafik keine Rolle. Da fällt es nicht auf wenn mal ein halbes Pixel daneben geht. In F95 ist sogar vierfache Genauigkeit drin. Beim gfortran ist es glaube ich Kind = 12.
10 oder 16 je nach Prozessor-Architektur.
Falsch, kann man definieren wie man will. 686er CPUs stellen 80bit-FP-Register zur Verfügung (KIND=10). "double double"/"quad" (KIND=16) gibts auch, ist aber blöd von Hand zu programmieren.
die 10 oder 16 bezogen sich ausschließlich auf gfortran. Und wenn ich der gfortran-Mailingliste glauben darf, dann wird immer nur eines von beiden unterstützt. Auch wenn beide von der Architektur unterstützt werden.
Deswegen verstecken die Fortran-Compiler es hinter den KIND-Parametern. Du kannst Dir mit SELECTED_REAL_KIND selbst Genauigkeitsbereiche definieren, ohne die unterliegende Hardware zu kennen, was Sinn und Zweck der Übung ist. (gfortran tut (tat?) das mit libmpfr und libgmp.)
libmpfr und libgmp werden ausschließlich zum reduzieren von konstanten Ausdrücken verwendet, damit das Programm auf allen Architekturen die gleichen Startwerte bekommt. Zur Laufzeit werden die Bibliotheken nicht verwendet.
Z.B.: REAL(KIND=8) :: x ! double REAL(KIND=SELECTED_REAL_KIND(100,50)) :: y ! 100 Dezimal(!)-Stellen Genauigkeit im Exponentenbereich 10^(-50) bis 10^50
Nenne mir einen Compiler, der das kann!
Die Kind-Parameterwerte sind dummerweise Kompilerabhängig.
Sind sie nicht, deren Funktionsweise ist im Standard definiert. Manche Compiler unterstützen manche KINDs nicht, s.o.
Falsch. Der Standard legt die funktionsweise der KIND-Parameter nicht auf Bytezahlen (wie bei gfortran,ifort u.a.) fest. Bytes gibt es im Fortran-Standard nämlich diesbezüglich nicht, um ihn auch auf exotische Architekturen anwenden zu können.
werden um zu prüfen, liege ich noch im Intervall oder bin ich im digitalen Nirvana.
Na ja, es gibt noch +Infinity, -Infinity und NaN.
Eigentlich müßte um jede Rechenoperation ein Exeptionhandling gemacht Und genau dafür kannst Du definieren, ob die FPU beim Auftreten eines solchen Wertes eine "Floating Point Exception" auslöst, und einen definierten "Exception Handler" ausführt. Diese Checks sind aber so teuer (zeitintensiv) und so umstritten (mehr Genauigkeit -- Bitstellen, s.o. -- langt meistens, oder ne Weiterbildung der Programmierer zur Vermeidung "klassischer Fehler"), daß sie kaum benutzt werden.
Ja, da war was von wegen signalisierenden und nicht signalisierenden NaNs.
Tobias.
On Wednesday 02 May 2007 20:47:30 Jan Rakelmann wrote:
Ich würde mal denke, doppelte Fließkomma-Rechnung spielt in der Computergrafik keine Rolle.
Bei OpenGL schon (Stichwort Fehlerfortpflanzung bei Matrixoperationen). Deshalb haben GPUs auch andere Befehlssätze und -Optimierungen als CPUs.
Josef
lug-dd@mailman.schlittermann.de
-
Jan Rakelmann -
Josef Spillner -
Sebastian Hegler -
Tobias Schlemmer -
Tobias Schlemmer -
willi_wotte＠woelunds.de