Unterstützt freie Software Quad Core?

[PunGNU]

Hey,
Die meisten Programme unterstützen ja noch nicht die Vier-kerner, wesswegen sich eine Anschaffung dieser nur bedingt lohnt. WIe sieht es denn hier mit freier SOftware aus? Freie SOftware ist in solchen Punkten ja immer ein bisschen fortschrittlicher. Ich benutze Debian GNU/Linux sid (Sidux) und Gentoo. Es heißt ja immer, dass die SOftware beim selbstcompillen unter Gentoo sich den Hardwarforraussetzungen anpasst, wesswegen Gentoo eine sehr gute Perfomence aufweist. Würde selbstcompillen einen Vorteil bringen?

 

[HisN]

In dieser Hinsicht unterscheidet sich die freie Software nicht von der Closed Source Software, es ist einfach davon abhängig ob sich die Anwendung parallelisieren lässt oder nicht.

 

[Sug82]

Ob selbstkompilieren was bringt, hängt davon ab, was du kompilierst und wie.
btw. was brauchst du von einem Programm, das alle 4 Kerne von Quadcore unterstützt, bin halt gespannt.

 

[PunGNU]

naja, die sache ist die, ich habe mir vor einem Monat einen e8400 + Mobo bestellt, da er nach dem was ich im Forum gelesen habe so dass beste P/L Verhälniss hat.
Der kommt und kommt jetzt aber nicht
Vor kurzem hab ich gehört, dass es im Linux-kernel einen Hotfix für den TLB-Bug gibt ohne bzw. mit minimalen performence Verlust. Dessweiteren habe ich gesehen dass der 9500 bei Ebay so um die 100 Euro verkauft wird. Da wollte ich wissen, ob dieser vllt. unter GNU/Linux mit dem e8400 mithalten könnte (da 4 Kern bei Freier Software unterstützt).

 

[Kamu]

es gibt mittlerweile auch eine neue rev. ohne tlb bug

http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1205396167

 

[philipp501]

Ich glaub du hast da etwas falsch verstanden, du kannst noch so viele Kerne haben, es gibt einfach ganz viel Software die sich nicht oder nur sehr begrenzt parallelisieren lässt. Das hat mit Open/closed source nichts zu tun. Auch der Kompiler kann da nicht viel ändern, Parallelisierung findet hauptsächlich im Quellcode statt.
Multicores bringen ansonsten nur dann einen Vorteil, wenn du viele Programme parallel laufen lässt.
Behalte lieber deinen 8400 und wenn es dir so wichtig ist solltest du den eher übertakten.

 

[aki]

Eine Parallelisierung kann man leider nicht durch das Kompilieren der Programme erzwingen. Wie bereits gesagt liegt dies einzig und allein am Quellcode.
Auch das Kompilieren selbst wird ohne Zutun nicht schneller durch einen Quadcore! Dies geschieht nur, wenn man make mit dem Parameter -j x startet und somit eine Anzahl gleichzeitig auszuführender Jobs mitgibt. Bei Gentoo gibts dazu extra den Eintrag MAKEOPTS="-jx in der make.conf.

Multicoreunterstützung ist in diesem Fall (gcc) also eher indirekt.

Es heißt ja immer, dass die SOftware beim selbstcompillen unter Gentoo sich den Hardwarforraussetzungen anpasst, wesswegen Gentoo eine sehr gute Perfomence aufweist.

Stimmt so nicht ganz. Die Software wird so optimiert, wie man es in der make.conf durch die CFLAGS etc. definiert. Automatisch wird das leider nicht durchgeführt.

Als Beispiel für richtige Multicoreunterstützung fällt mir dvd::rip ein. Das sogar mit Cluster-Support

 

[PunGNU]

ok danke für eure Antworten.
Ach eine frage hätt cih ncoh. DIe 64 Bit unterstüzung wird ja beim Compillen "mitreinbracht" oder ist es da so ähnlich wie bei den Multi-cores, dass man es im Quelltext einbind (z.b. durch paralysierung o.ä.) muss?

 

[philipp501]

Ist fast immer durch den Quellcode gegeben. Was willst du denn kompilieren?

 

[PunGNU]

Nichts ^^
Hat mich nur mal so interessiert

 

[Sensei21]

Eine Parallelisierung kann man leider nicht durch das Kompilieren der Programme erzwingen.

hm,

...













doch

der spaß fängt erst mit gcc-4.3.X richtig an:

Highlights include:
(these are not new for users of the 4.3.0 experimental releases)

* Better optimizations and vectorizations
* Automatic parallelization (-ftree-parallelize-loops)
(though explicit OpenMP (-fopenmp) or MPI parallization usually are
much superior)
* Possibility to call external BLAS routines for operations such as
MATMUL.
* Initialize local variables to zero (or other values)
* Support of the GAMMA and LGAMMA functions
(GAMMA and LOG_GAMMA are also part of the Fortran 2008 draft)
* BOZ: Support F2003 BOZ and better compatibility with other vendors
for non-standard BOZ
* Fortran 2003:
- Intrinsic statements IMPORT, PROTECTED, VALUE and VOLATILE
- Pointer intent
- Intrinsic module ISO_ENV_FORTRAN
- Interoperability with C (ISO C Bindings)
- ABSTRACT INTERFACES and PROCEDURE statements (without POINTER
attribute)
- Fortran 2003 BOZ

--> man kann also sowohl im vorhinein im code festlegen zu parallelisieren & das nachträglich hinzufügen

und natürlich der obligatorische -march=core2

(quelle)

changes.html

wenn die so weitermachen wird das ohnehin schon schnelle gcc (momentan hab ich 4.2.3 drauf) + system so schnell wie nie

gcc ist mittlerweile in vielen szenarien schneller als intels icc compiler

(ich beobachte schon seit jahren einen trend, dass die software immer weniger speicher benötigt, immer mehr kann & immer schneller wird, sogar auf 4-6 jahre alter hardware )

 

[aki]

Danke für die Richtigstellung.
Ich zieh (fast) alles zurück und behaupte das Gegenteil Da hab ich wohl die Changelogs von Gcc etwas vernachlässigt.

Bleibt nur die Bedingung, dass man die make.conf mit allen Optimierungen und Einstellungen richtig gestaltet. Ansonsten gäbe es auch mit Gentoo keine Vorteile.


mfg
aki

 

[Sensei21]

wenn du die use-flags in deine aussage einbeziehst, stimm ich dir eigentlich vollständig zu (weniger funktionen bringen schließlich auch was in der performance, wenn nicht unbedingt bei multicore rechnern)

weiters gibt es ja noch die unterschiedlichen profile (hardened, default, server, selinux) aber die passen hier nicht rein

von dem her ist opensource um einiges besser für die "zukunft" (== multiple threads) gerüstet

 

[aki]

Ich denke ich habe mich gestern einfach falsch ausgedrückt.
Parallelisierung hin oder her, ich meinte tatsächliche Multicoreunterstützung. Ich glaube kaum, dass z.B. mencoder plötzlich anstatt einer CPU alle im System vorhandenen CPUs benutzt, nur weil ich nun -fopenmp nutze. Das müsste doch trotzdem weiterhin durch die Programmierung erledigt werden, oder versteh ich hier was falsch? Bitte klär mich auf

 

[FreddyMercury]

Doch das sollte gehen. Zumindest soweit ich weiss kann das Programm wenn man mit Threads programmiert, automatisch auf die CPU's auslegen. Und wenn das mit gcc-4.3 stimmt und OpenMP mal weiter vorankommt, seh ich das genauso wie Freak01

Lass mich aber auch gern des besseren belehren

 

[Krik]

Die Software muss mit Threads arbeiten, sonst bringen Multicore-CPUs nichts.
Das ist sowohl unter Windows als auch unter Linux so.

Da nützt es auch nichts, beim Kompilieren auf Multicore-Unterstützung des Compilers zu hoffen. Es liegt alleine daran, wie das Programm konzeptiert ist. GCC kann nur optimieren, aber nicht aus einem Single-Core-Programm ein Multi-Core-Programm zaubern.

 

[aki]

Genau das ist der Punkt, den ich eigentlich meinte. Multicoreunterstützung kann der Compiler nicht erzwingen, Parallelisierung war da einfach der falsche Begriff.
OpenMP ist schon seit Version 4.2 integriert, kann aber auch nur Optimieren und nicht Zaubern. Gcc wäre ja ein Wunderwerk, wenn es jedes Programm multicorefähig machen könnte.

 

[FreddyMercury]

ABer es reicht doch schon alleine mit pthreads oder so zu arbeiten.

 

[Sensei21]

anscheinend basiert das alles auf pthreads,

http://forums.gentoo.org/viewtopic-p-4948799.html#4948799

-ftree-parallelize-loops=n
Parallelize loops, i.e., split their iteration space to run in n threads. This is only possible for loops whose iterations are independent and can be arbitrarily reordered. The optimization is only profitable on multiprocessor machines, for loops that are CPU-intensive, rather than constrained e.g. by memory bandwidth. This option implies -pthread, and thus is only supported on targets that have support for -pthread.

kommentar dazu:

Veeeeewy interesting...

Causes ICEs and miscompilations when combined with vectorisation though.

http://gentoo-wiki.com/CFLAGS_matrix

-ftree-parallelize-loops=n Tries to split logic intensive loops into parallel operations. Intended for SMP systems. New switch in GCC 4.3, often causes miscompilation when combined with vectorisation, in which dependencies may fail on depended packages compiled with both switches. Based on OpenMP.

also ist schon ein bißchen "magic" im spiel

ausprobieren will ich das jetzt aber nicht, dazu sind mir meine daten zu schade, ich warte lieber auf gcc-4.3.1 oder 4.3.2, dann sehen wir weiter ...

wirklich viel infos gibt es dazu noch nicht, dazu müsste man die gcc programmierer mal anschreiben & nachfragen, die scheinen momentan aber recht viel zu tun zu haben

 

[Kommandofrosch]

Gerade SMP also Multiprocessing ist ein klarer Bonus für die Unix und Opensource - Unixwelt.
Die waren da schon jahre weiter als MS und Apple.
Die folgenden Linuxkernel sollen ja tausende Prozessoren auf einem System unter einem Kernel
unterstützen. Clustersysteme und Supercomputer mit astronomisch großem Ausmaß sowie
Backbones von vielen Inetprovidern laufen schon lange auf freien Unixen.