Peter Ross wrote:
> On Fri, 5 Sep 2003, Bernd Walter wrote:
>
>
>>Der Compiler hat keine Ahnung von Threads.
>
>
> Ja. Was ich meinte, ist, ob es nuetzlich ist, einem Compiler zu haben, der
> weiss, dass eine CPU aus zwei logischen besteht und Teile des Codes
> paralilisiert?
Fortran kann sowas.
> Da muesste dann aber das OS so gestrickt sein, dass es dem so
> entstandenen "Parallel-Code" eine ganze CPU mit beiden logischen
> ueberlaesst.
>
> Vorteil waere eben, dass der Compiler gut die Daten arrangieren kann, die
> halt in CPU-Caches und Registern liegen. Sie wuerden fuer beide logischen
> CPUs aus dem selben Prozess stammen.
Aber die CPU's haben unterschiedliche Register!
> Nachteilig waere, dass, wenn dann ein nicht so kompiliert wurde, die
> zweite logische CPU brachliegen wuerde. Auch, wenn der Prozess sogar zwei
> Threads haette, die sich gegenseitig ergaenzen.
>
> Damit das OS beides machen kann, muesste ein compileroptimiertes Programm,
> welches gern beide logischen CPUs haette, das beim Scheduler anmelden
> koennen, d.h., es muesste dazu die Prozessstruktur erweitert werden.
Klingt erstmal logisch. Allerdings ist die 2. logische CPU speziell
dafür gedacht, nicht optimierte Threads den Prozessor optimal
auszulasten. Siehe dazu auch die Compiler-Flags '-fschedule-insns'
bzw. '-fschedule-insns2'. Die können nämlich - wenn der Code es
zulässt, den Prozessor auch ohne 2. logische CPU dichtmachen.
> Wobei das sogar noch halbwegs uebersichtlich ist, wenn eine CPU aus zwei
> logischen Einheiten besteht. Wenn wir erst einmal drei, vier oder zwanzig
> haben, skaliert dieser Ansatz nicht besonders gut..
>
> Scheint nicht gar so einfach zu sein, Hyperthreading sinnvoll zu nutzen..
Doch, allerdings ist es wie gesagt für nicht optimierten Code für die
vorhandenen Recheneinheiten gedacht.
> Gruss
> Peter
Gruß,
Jens
To Unsubscribe: send mail to majordomo.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 05 Sep 2003 - 13:44:57 CEST