| View previous topic :: View next topic |
| Author |
Message |
Terrere
n00b
Joined: 03 Sep 2006
Posts: 73
Location: Basel (CH)
|
 Posted: Sat Jul 17, 2010 10:30 am Post subject: |
 |
|
Ich bin Windows/KDE frei
hehe, ja mei, Spass muss sei.
KDE hat mir damals das Einleben in Linux sehr erleichtert, war so mit Suse 7.
Nicht das ich jetzt ein Crack wär,
finde aber nun mittlerweile meine Daten auch ohne Konqi.
D-Bus, Hal, QT, Consolekit, andere "Sinnvolle Progs" wurden schon genannt.
In Linux gibts Hass-Tools wie Sand am Meer.
P.s. Natürlich gibts auch ne Schattenseite, wen man Gentoo nur mit lausigen
447 Packeten fährt; es gibt NICHT täglich was zum emerge -avutDN world
 |
|
| Back to top |
|
 |
musv
Advocate
Joined: 01 Dec 2002
Posts: 3337
Location: de
|
| Posted: Tue Jul 20, 2010 8:37 am Post subject: |
|
|
Der nächste blöde Paukenschlag bei KDE. Ich hab's noch nicht weiter getestet, warum und was, aber:
Digikam will Fortran haben
Jetzt fragt man sich: Warum benötigt eine Applikation basierende auf KDE4 auf einmal Fortran? Ich mein, die Programmiersprache ist von 1957 und sollte eigentlich nur noch in irgendwelchen Dinosaurierindustrieapplikationen vorkommen, die aus irgendwelchen Gründen noch nicht refactored wurden.
Bisher ist der Stand so, dass ich viele KDE-Apps eigentlich noch mag. Mal sehen, wenn ich dem ein Ende setz. Eventuell ist's auch nur ein fälschlich eingebautes Use-Flag. Werd das beim nächsten größeren Update (4.5?) mal testen. |
|
| Back to top |
|
|
Klaus Meier
Advocate
Joined: 18 Apr 2005
Posts: 2908
Location: Bozen
|
| Posted: Tue Jul 20, 2010 8:41 am Post subject: |
|
|
| Bei mir lässt sich KDE4 nur installieren, wenn ich im gcc Fortran aktiviere. Irgendwas braucht das, keine Ahnung was. |
|
| Back to top |
|
|
Finswimmer
Bodhisattva
Joined: 02 Sep 2004
Posts: 5467
Location: Langen (Hessen), Germany
|
| Posted: Tue Jul 20, 2010 8:44 am Post subject: |
|
|
Das scheint aber ein Gentoo Problem zu sein:
| Quote: | # gcc[fortran] is required since we cannot otherwise link to the lapack library
# (the fun of unbundling)
DEPEND="${CDEPEND}
sys-devel/gcc[fortran]
sys-devel/gettext
"
|
_________________
Bitte auf Rechtschreibung, korrekte Formatierung und Höflichkeit achten!
Danke |
|
| Back to top |
|
|
Finswimmer
Bodhisattva
Joined: 02 Sep 2004
Posts: 5467
Location: Langen (Hessen), Germany
|
| Posted: Tue Jul 20, 2010 9:09 am Post subject: |
|
|
| Klaus Meier wrote: | | Bei mir lässt sich KDE4 nur installieren, wenn ich im gcc Fortran aktiviere. Irgendwas braucht das, keine Ahnung was. |
Das liegt dann auch an Digikam.
Im gesamten Portage hängen nur Digikam und open64 von gcc[fortrane] ab.
Tobi
_________________
Bitte auf Rechtschreibung, korrekte Formatierung und Höflichkeit achten!
Danke |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Tue Jul 20, 2010 6:47 pm Post subject: |
|
|
| musv wrote: | | Digikam will Fortran haben |
Das hingegen finde ich eine verständliche Forderung von digicam: lapack ist die Standard-Mathematik-Bibliothek, und die ist halt nun mal in fortran geschrieben. Dass eine Bildverarbeitung auf eine bestehende Mathematik-Bibilothek zugreift statt das Rad selbst neu zu erfinden, ist vernünftig. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Tue Jul 20, 2010 6:50 pm Post subject: |
|
|
| Finswimmer wrote: | | Im gesamten Portage hängen nur Digikam und open64 von gcc[fortrane] ab. |
Ja nun: lapack kann außer mit gcc[fortran] experimentell auch noch mit Intels Fortran-Compiler compiliert werden. De facto hat man hier aber eine (nicht in DEPEND genannte sondern nur zur Compile-Zeit überprüfte) Abhängigkeit von gcc[fortran]. |
|
| Back to top |
|
|
musv
Advocate
Joined: 01 Dec 2002
Posts: 3337
Location: de
|
| Posted: Wed Jul 21, 2010 10:18 pm Post subject: |
|
|
| mv wrote: | | musv wrote: | | Digikam will Fortran haben |
Das hingegen finde ich eine verständliche Forderung von digicam: lapack ist die Standard-Mathematik-Bibliothek, und die ist halt nun mal in fortran geschrieben. Dass eine Bildverarbeitung auf eine bestehende Mathematik-Bibilothek zugreift statt das Rad selbst neu zu erfinden, ist vernünftig. |
Gut akzeptiert. Warum ist die Bibliothek aber jetzt noch in Fortran geschrieben. Hätte man die nicht irgendwann mal in den letzten Jahrzehnten portieren können?
Die Edith hat grad Lapack++ gefunden. Sieht doch auf den ersten Blick vielversprechend aus. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Wed Jul 21, 2010 10:37 pm Post subject: |
|
|
| musv wrote: | | Gut akzeptiert. Warum ist die Bibliothek aber jetzt noch in Fortran geschrieben. Hätte man die nicht irgendwann mal in den letzten Jahrzehnten portieren können? |
Leider ist bis heute Fortran die Sprache der Mathematik-Software: Dort sind beispielsweise komplexe Zahlen und Rechnen mit hohen Genauigkeiten Bestandteil der Sprache. In C++ kann man das zwar als Klassen "emulieren", aber es ist halt nicht der Standard (und die Implementation langsamer, da naturgemäß in C++ selbst geschrieben). Gerade auf Großrechnern mit extremer Rechenleistung gibt es oft extrem gute Fortran-Compiler, die noch ein Fizzelchen effizienter sind - und bei numerischen Problemen kommt es darauf oft an, weil für das Anmieten eines solchen Rechners für einen Tag dann viel Geld bezahlt wird, und am Ende des Tages sollte ein riesiges numerisches Problem dann auch gelöst sein.
Da auf solchen Rechnern dann eben der lapack/blas-Standard existiert (und dort meist hochoptimiert von einer Spezialfirma implementiert wurde), wird der dann halt auch auf kleineren Rechnern benutzt. Den Standard zu ändern, dürfte also schwierig sein.
Edit: Soweit ich weiß, ist lapack++ i.W. eine wrapper-Bibliothek: Sie macht es bequem, lapack/blas von C++ aus zu nutzen. Die Bibliothek selbst greift dabei aber auf den Origial fortran-Code zurück (wobei ich jetzt nicht weiß, ob der vollständig oder nur teilweise von einem fortran-to-c-compiler zuvor "bearbeitet" wurde); ich vermute, die Chancen sind gut, dass man für die Compilation von lapack++ daher ebenfalls gcc[fortran] benötigt. |
|
| Back to top |
|
|
musv
Advocate
Joined: 01 Dec 2002
Posts: 3337
Location: de
|
| Posted: Thu Jul 22, 2010 9:13 am Post subject: |
|
|
| ok danke, wieder was gelernt. |
|
| Back to top |
|
|
manuels
Advocate
Joined: 22 Nov 2003
Posts: 2146
Location: Europe
|
| Posted: Thu Jul 22, 2010 11:57 am Post subject: |
|
|
| mv wrote: | | Dort sind beispielsweise komplexe Zahlen und Rechnen mit hohen Genauigkeiten Bestandteil der Sprache. |
Sorry, jetzt wirds ein bisschen offtopic:
C++ bietet die selbe Genauigkeit und ebenfalls komplexe Zahlen.
Meiner Erfahrung wird Fortran in den Naturwissenschaften genutzt, da die Profs zu faul sind/keinen Grund sehen eine neue Programmiersprache zu lernen.
Als sie studiert haben, gab es Fortran. Und dabei sind sie geblieben.
_________________
Build your own live cd with catalyst 2.0! |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2285
Location: Adendorf, Germany
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Thu Jul 22, 2010 5:58 pm Post subject: |
|
|
| manuels wrote: | | mv wrote: | | Dort sind beispielsweise komplexe Zahlen und Rechnen mit hohen Genauigkeiten Bestandteil der Sprache. |
Sorry, jetzt wirds ein bisschen offtopic:
C++ bietet die selbe Genauigkeit und ebenfalls komplexe Zahlen. |
Das schrieb ich ja, aber beides gibt es in C++ nur indirekt über zusätzliche Klassen, nicht als Teil der "nativen" Sprache. Daher ist beides langsamer. (Dabei spielt es keine Rolle, ob es die "complex"-Klasse per Standard in jedem C++-Compiler zu geben hat: Es bleibt trotzdem eine zusätzliche Klasse und ist kein nativer Datentyp wie int,float,double. Für Rechnen mit beliebigen Genauigkeiten, Intervallarithmetik, o.ä. gibt es m.W. in C++ gar keinen Standard, sondern nur verschiedene unabhängige Bibliotheken. Wenn man dann mehreres kombinieren will, sieht es erst recht mau aus). |
|
| Back to top |
|
|
Treborius
Guru
Joined: 18 Oct 2005
Posts: 585
Location: Berlin
|
| Posted: Thu Jul 22, 2010 6:34 pm Post subject: |
|
|
| mv wrote: | | manuels wrote: | | mv wrote: | | Dort sind beispielsweise komplexe Zahlen und Rechnen mit hohen Genauigkeiten Bestandteil der Sprache. |
Sorry, jetzt wirds ein bisschen offtopic:
C++ bietet die selbe Genauigkeit und ebenfalls komplexe Zahlen. |
Das schrieb ich ja, aber beides gibt es in C++ nur indirekt über zusätzliche Klassen, nicht als Teil der "nativen" Sprache. Daher ist beides langsamer. |
klinkt mich mal offtopic ein :
wenn du eine Klasse "complex" als POD schreibst (was in C++ ohne weiteres möglich ist) gibt es meiner meinung nach absolut keinen
geschwindigkeitsunterschied zwischen fortran und C++
ist doch egal ob Klasse oder nativ, für ne Addition von 2 complexen Zahlen muss der Prozessor genau die selben 2 ADDs machen,
ob nun fortran oder C++
_________________
Systems running gentoo :
Desktop, Laptop, ZOTAC AD-10 media-center, odroid-xu4 server / wLan-router |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Thu Jul 22, 2010 10:37 pm Post subject: |
|
|
| Treborius wrote: | ist doch egal ob Klasse oder nativ, für ne Addition von 2 complexen Zahlen muss der Prozessor genau die selben 2 ADDs machen,
ob nun fortran oder C++ |
Für eine Operation, ja. Für Formeln (etwa x=a+b*c) muss aber beispielsweise der Compiler haufenweise temporäre Objekte erzeugen, die - wenn man mit Rechenregeln für komplexe Zahlen vertraut ist - durch Kommutativität der Addition oder Verwerfen vermieden werden können. Solche Annahmen kann ein Compiler aber bei Klassen im allgemeinen nicht machen. Abgesehen davon, dass ein guter Compiler anhand der Formellänge u.ä. entscheiden kann, ob er die Zahlen nun im Format (Real,Imag) abspeichert, oder ob sich des Erzeugen und Merken eines Zwischenergebnisses z.B. in Polarkoordineten für spezielle Multiplikationen oder Potenzierungen lohnt. Für die built-in-Typen nennen sich solche Optimierungen beim gcc CFLAGS=-ffast-math |
|
| Back to top |
|
|
|
Deutsches Forum (German)
