News Intels neue Compiler für Multicore optimiert

[Frank]

Intels neue 9.0-Compiler für C++ und Fortran sind ab sofort speziell für Multithread- und somit auch Multicore-Anwendungen optimiert. Intel stellt die neuen Compiler sowohl für Windows als auch für Linux zur Verfügung.

Zur News: Intels neue Compiler für Multicore optimiert

 

[Boron]

Komisch, dass es erst neue Prozessoren braucht, dass die Menschheit erkennt, dass Multithreaded Programme irgendwie cooler sind als Singlethreaded Programme.
Immerhin unterstützten alle modernen Betriebsysteme sowohl Multitasking als auch Multithreading.
Aber irgendwie meint jeder (oder die meisten), dass Arbeitsabläufe streng sequentiell ablaufen müssen.
Kaum wird eine Filterfunktion in einer Bildverarbeitung aktiviert, schon blockiert das gesamte Programm, bis der Filter fertig berechnet wurde.
Kaum öffne ich in Firefox im Internet ein PDF, schon blockiert der Browser eine gewisse Zeit.

Dabei lassen sich viele Aufgaben in eigene Threads auslagern, was einem flüssigen Arbeiten zu Gute kommt. Überhaupt profitiert ein System in seiner Geschwindigkeit durch viele kleine Aufgaben. Das ist besser als wenn es nur große langwierige Aufgaben gibt.

 

[bensen]

tja aber einen einzelnen prozessor bringt das alles nichts und dual prozzi systeme waren bisher zu teuer
dualcore ist ne billige lösung für den kompletten makt
also lohnt es auch dafür zu entwickeln

 

[Spacy]

Das MT-Prgramme irgendwie cooler sind hat Nintendo schon mit dem N64 gemerkt ^^

 

[KRambo]

tja aber einen einzelnen prozessor bringt das alles nichts und dual prozzi systeme waren bisher zu teuer
dualcore ist ne billige lösung für den kompletten makt
also lohnt es auch dafür zu entwickeln

Es muss ja kein DualCore sein, für MT-Proggies reicht auch HT. Find ich auch besser, alles was möglich ist in eigene Threads auszulagern, damit das Hauptproggie noch auf Eingaben reagieren kann

 

[fibric]

selbst singlecore prozessoren arbeiten mehre threads "gleichzeitig" ab. der programmierer muss nur dafür sorgen dass er seine aufgaben windows like programmiert... dass sowas geht sieht man daran dass anwendungen einen "abbrechen button" haben mit dem man eine komprimierung, convertierung oder ein encoding vorgang abbrechen kann. würde die anwendung strikt single threaded arbeiten würde der "abbrechen button" erst wieder anklickbar sein wenn die arbeit beendet wurde...

 

[KRambo]

Genau siehe die meisten VB6 (oder älter) Anwendungen da gabs kein Threading drin

 

[kaepten]

@Boron
Ich gebe Dir im Kern Deiner Aussage recht. Dennoch ist threaded programmieren auch nicht ohne. Es ist wohl immer einfacher sequenziell zu arbeiten. Eines nach dem anderen... Keine Synchronisation nötig, keine concurrent Dataacesses, locking etc. etc... Es geht wohl um die erhöhte Komplexität die man meidet, wenn man rein sequenzielle Prozesse abwickelt.

Mich würde mal interessieren, wie viel mehr Aufwand man in threaded programmierte Anwendungen stecken muss, im gegensatz zum Aufwand für sequenzielle.

kaepten

 

[Boron]

@kaepten
Ob sich der Mehraufwand in % ausdrücken lässt glaube ich nicht. Das ist viel zu stark von der Anwendung und der "Parallelisierbarkeit" abhängig.
Dass der Aufwand bedeutend größer ist dürfte klar sein. Du hast die Punkte ja genannt: Synchronisation und Schutz der Daten.

Wenn durch Compiler, die die Entwickler unterstützten weg vom "sequentiellen Denken" und hin zum "parallen Denken" zu kommen, dann ist das sehr zu begrüßen.
Dann hoffe ich mal, dass sich in Zukunft viel mehr in Richtung Multithreaded Programme tut. Mit Compilern, die so etwas fördern geht es bestimmt leichter (in der Hoffnung, dass sich die Entwickler nicht nur auf die Fähigkeiten der Compiler verlassen ).

 

[kaepten]

@Boron
Ich denke, dass der Compiler ja eigentlich nur die "einfachen" Dinge selbst als threadet umwandeln kann. Sicherlich ist das bereits ein guter Fortschritt. Dennoch sind es wohl die "grossen" Brocken, die der Entwickler ganz explizit threadet machen muss. So wie es heute - es wurde schon angesprochen - eigentlich schon problemlos funktioniert. (Siehe mein Beispiel-versuch unten). Nun kann einfach der Compiler bereits seinerseits seine Befehle threadet ausführen -> also ein kleinerer Teilbereich des grossen Ganzen.

@[FiBRiC]
Naja so ähnlich. Ich muss nicht wirklich threadet programmieren um das zu ermöglichen was Du erwähnst. Es geht weniger darum, die Möglichkeit zu haben etwas zu unterbrechen was lauft, sondern vielmehr zwei Dinge gleichzeitig auszuführen: Also dass ich komprimieren und compilieren und encodieren gleichzeitig machen kann. Und das innerhalb derselben Anwendung.

Beispiel:
Ich habe eine Suchfunktion die bringt mir Resultate aus drei unterschiedlichen Datenbanken (unterschiedliche Server). Um das ganze Resultat zu ermitteln, muss ich also auf drei unterschiedliche Quellen eine Abfrage machen. Solche Abfragen können mitunter einige sekunden, wenn nicht Minuten dauern.

Nach dem klick auf "Suchen" passiert also vereinfacht gesagt folgendes:

Sequenziell:
1. Suche in DB1, warten auf Suchresultat (ablegen in Memory) [1 min]
2. Suche in DB2, warten auf Suchresultat (ablegen in Memory) [2 min]
3. Suche in DB3, warten auf Suchresultat (ablegen in Memory) [3 min]
4. Suchresultate 1 bis 3 mergen und anzeigen

Total = 6 minuten

Threadet:
1. Suche in DB1 starten
2. Suche in DB2 starten
3. Suche in DB3 starten
2. Warten bis alle Suchen status "abgelegt in Memory" zurückmelden [3 min]
4. Suchresultate 1 bis 3 mergen und anzeigen

Total = 3 min

kaepten

 

[Scotty4BMAN]

Der Mehraufwand für die Erstellung von Threaded-Apps ist auf jeden Fall enorm.

Das Problem vom kaepten mit der Datenbank scheint ja so relativ simpel lösbar(und würde übrigens normalerweise auch auf einem Single-Prozessorsystem ohne HT schneller fertig), aber solche nahezu vollständig von einander unabhängigen Teilprobleme treten auch relativ selten auf. Viel häufiger trifft man auf Probleme, die sich in Teilgebieten überschneiden, wo sie dann synchronisiert werden müssen. Der Compiler kann einem bei sowas schon nicht mehr helfen, auch mit dem Datenbank Beispiel sollte der Compiler überlastet sein und brauch die Hilfe vom Programmierer.

Wo der Compiler durch OpenMP bisher immer die größten Performancegewinne erreichen konnte war beim loop unrolling. Dein 6min : 3min Fall wird wohl auch die nächsten Jahre nicht allein durch Compileroptimierungen zu erreichen sein.

Was mich bei der Entwicklung von Multithreaded Apps immer am meisten gestört hat, ist das ungleich kompliziertere Debugging und die häufig damit verbundene schlechtere Qualität des Endprodukts, da MT-Bugs unglaublich schwer zurückverfolgbar sind.

 

[The_Jackal]

Wenn dieser Schritt wenigstens gemacht werden würde. Warum unterstützt denn Windows und andere OS Multithreading, wenn kein Progarmm es nutzt?

Alles läuft nacheinander ab.

Wenn jetzt jemand kommt mit: "Ich habe doch Winamp gleichzeitig laufen mit meinem Browser und einen Word Dokument" - dann gibt's Hause

Diese Sachen werden trotzdem nacheinander abgehandeln, zwar absolut schnell, also die CPU wechselt dann ganz schnell zwischen Word und Winamp und was so angefragt wird, aber SingleTh bleibt SingleTh.

Für Anwendungen wie Spiele würde sich das nämlich echt lohnen oder für große Grafikprogramme, aber selbst Office würde gut profitieren davon, wenn viele Sachen praktisch gleichzeitig gemacht werden müssen.

Vielleicht kommt es ja für manche Programme bald.

Gibt es eigentlich inzwischen ein MultiThreading Benchmark Programm?

 

[intel]

Nun hat einer von euch sich schon mal gedanken gemacht warum man bisherige Software nur für einen Prozessor optimiert? Weiss jemand wie viel Arbeit das ist einen Algorithmus auf MT umzuschreiben? Sinnvoll ist das sowieso nicht bei allen Algorithmen und in den meisten Systemen laufen ja heute schon an die 50 Threads nach dem Start.

Vieleicht kann mir ja erstmal einer von euch erklären wo der Unterschied zwischen Thread und Prozess liegt, bevor er sich anmaßt darüber zu urteilen was Leute, die sich mit Prozessoren auskennen, dazu bewegt ihre Programme in wenig Threads zu zerlegen.

 

[Scotty4BMAN]

@13
Wo laufen 50 Threads nach dem Start ? meintest du evtl. Prozesse ?

 

[Siberian..Husky]

Wenn dieser Schritt wenigstens gemacht werden würde. Warum unterstützt denn Windows und andere OS Multithreading, wenn kein Progarmm es nutzt?

Alles läuft nacheinander ab.

Wenn jetzt jemand kommt mit: "Ich habe doch Winamp gleichzeitig laufen mit meinem Browser und einen Word Dokument" - dann gibt's Hause

Diese Sachen werden trotzdem nacheinander abgehandeln, zwar absolut schnell, also die CPU wechselt dann ganz schnell zwischen Word und Winamp und was so angefragt wird, aber SingleTh bleibt SingleTh.

Für Anwendungen wie Spiele würde sich das nämlich echt lohnen oder für große Grafikprogramme, aber selbst Office würde gut profitieren davon, wenn viele Sachen praktisch gleichzeitig gemacht werden müssen.

Vielleicht kommt es ja für manche Programme bald.

Gibt es eigentlich inzwischen ein MultiThreading Benchmark Programm?

also ich glaube du bringst da einiges durcheinander. für einen prozessor sind threads und anwendungen genau das selbe. eine anwendung hat immer mindestens einen thread. ob die cpu nun verschiedene threads einer anwendung oder verschiedener anwendungen abarbeiten soll macht eigentlich überhaubt keinen unterschied.

der leistungsgewinn von HT ist bei intel auch nur so groß weil die netburst architektur extrem ineffektiv arbeitet. normalerweise sollte eine CPU durch neuordnung der ankommenden befehle dazu in der lage sein sich selbst so gut wie möglich auszulasten. das macht amd wesentlich besser, daher ist dort auch kein HT nötig.

auf einer ganz normalen singlecore cpu gibt es durch verschiedene thread also eher leistungs einbußen da der scheduler mehr zutun hat.

der eigentliche vorteil von threads auf aktuellen desktop pcs ist der bessere code. programme die threads benutzen haben wesentlich übersichlichere ausführungspfade und sind somit viel einfacher zu debugen und zu verstehen. denn das blockieren einer anwendungen lässt sich auch ohne thread relativ einfach umgehen. man muss nur dafür sorgen das die nachrichten verarbeitung des programms oft genug ausgeführt wird, und schon kann man auch einen single thread encoder stoppen bevor er mit dem encodieren fertig ist.

am ende ist es aber offenbar für viele programmierer wichtiger am schnellsten zu ergebnissen(=vielen features) zu kommen, anders kann man diese schlechten singlethread beispiele aus diesem thread zumindest nicht erklären.

 

[kaepten]

am ende ist es aber offenbar für viele programmierer wichtiger am schnellsten zu ergebnissen(=vielen features) zu kommen

Mooooooment! Bist Du vom Wahnsinn umzingelt?

Ein Programmierer ist ein Entwickler und Tüftler. Technologie ist für Ihn täglich Brot, er liebt Technik und wo er optimieren kann (Stabilität, Geschwindigkeit) würde er nicht zögern das zu tun, wenn;

Wenn er nicht unter der Geissel der Projektleiter bzw. Geldgeber leiden müsste: immer Schneller, immer billiger, immer mehr Showeffekte(Funktionen)...

Darum ist es nie der Prgrammierer, der die Features vor Qualität vorzieht. Es sind die Verkäufer, das Marketing und das ganze Gesindel, für die nur Masse anstelle Stabilität und Geschwindigkeit zählt! Hauptsache der Rubel roll. Programmierer sind eher Idealisten, für die zählt in erster Linie Technik und nicht der Rubel --- Deshalb werden wir immer arm bleiben...

Nur damit das klargestellt ist! Und ich bin sicher ich spreche hier für die 80% der Entwickler wo das zutrifft!

kaepten

 

[Boron]

Vieleicht kann mir ja erstmal einer von euch erklären wo der Unterschied zwischen Thread und Prozess liegt, bevor er sich anmaßt darüber zu urteilen was Leute, die sich mit Prozessoren auskennen, dazu bewegt ihre Programme in wenig Threads zu zerlegen.

Diese Erklärung ist ganz gut: http://de.wikipedia.org/wiki/Thread
Ich ergänze, dass in der Erklärung "Prozess" und "Task" die selbe Bedeutung haben.

PS: Ich habe mein Diplom als Technischer Informatiker. Ich bilde mir ein zu wissen wo die Vorteile liegen wenn Programme sinnvoll in Threads aufgeteilt werden .

 

[MacGyver]

Mooooooment! Bist Du vom Wahnsinn umzingelt?

Ein Programmierer ist ein Entwickler und Tüftler. Technologie ist für Ihn täglich Brot, er liebt Technik und wo er optimieren kann (Stabilität, Geschwindigkeit) würde er nicht zögern das zu tun, wenn;

Wenn er nicht unter der Geissel der Projektleiter bzw. Geldgeber leiden müsste: immer Schneller, immer billiger, immer mehr Showeffekte(Funktionen)...

Darum ist es nie der Prgrammierer, der die Features vor Qualität vorzieht. Es sind die Verkäufer, das Marketing und das ganze Gesindel, für die nur Masse anstelle Stabilität und Geschwindigkeit zählt! Hauptsache der Rubel roll. Programmierer sind eher Idealisten, für die zählt in erster Linie Technik und nicht der Rubel --- Deshalb werden wir immer arm bleiben...

Nur damit das klargestellt ist! Und ich bin sicher ich spreche hier für die 80% der Entwickler wo das zutrifft!

kaepten

Für mich sprichst du auf jeden Fall.
Und das ist auch für mich der Hauptgrund warum Windows instabiler und anfälliger ist als beispielsweise Linux. Den MS Entwicklern sitzen auch die Projektleiter im Nacken und MS hat davon eine ganze Menge. Da wird so ein Druck aufgebaut dass manche Entwickler zum psychischen und physischen Wrack werden. Keine Zeit, viele Funktionen, kaum Zeit zum Testen des ganzen Systems.
Klar dass das Buggy wird. Aber man kann nicht sagen dass bei MS schlechte Programmierer sitzen. Es liegt hauptsächlich am strengen Projektplan dass Windows löchricg wird wie ein schweizer Käse.

 

[The_Jackal]

[...]

kaepten

Tja, aber der Entwickler, der auf Qualität setzt, vergisst gerne das liebe Geld. Es kann nicht sein, dass man munter vor sich hin programmiert und entwickelt, solange man in einer Firma angestellt ist. Das kannst du machen, wenn du in F&E wärst, z.B. Grundlagenforschung und die Gelder dafür da sind.

Solange du in einer Firma bist, die eben Geld verdienen will, wirst du zielstrebig arbeiten müssen und da kannst du froh sein, dass das "Marketing Gesindel" dir deinen Job rettet, denn ohne die, wärst dein Programmieren zu teuer.

Solange der Kompromiss zwischen Features und Leistung okay ist, ist das ganze Projekt gut.


.

 

[kaepten]

@The_Jackal
Ich gebe Dir auf der ganzen Linie recht! Wie überall auf der Welt muss es in der Waage sein.

Es ist richtig, die Kehrseite der Entwickler und dessen Idealismus ist sicher die "Detailverliebtheit" oder "Technikverliebtheit". Manchmal wollen wir zu vorausschauen und zu generisch bleiben - möglichst offen für was noch kommen kann. Aber das bedeutet Aufwand = Zeit = Geld.

Leider ist es aber eher so, dass die meisten Entwickler genug Vernünftig wären und keinen Overhead produzieren wollen. Tatsache ist, dass sie nicht mal die Zeit/Geld bekommen um nur das minimalste an Qualitätssicherheit in das Produkt zu stecken. Aber danach wundert sich die ganze Welt - allen voran der PL oder der Sponsor (Geschäftsleitung) Warum das Proggie so Buggie ist. *staunstaun*. Schnell werden Qualitätssicherungsmassnahmen vorgeschlagen und schriftlich festgehalten. Die sind so schnell wie sie da waren wieder über den Haufen geschmissen, wenn das nächste Projekt zu wenig Budget für den geforderten Umfang hat! *PLsäuselnd* da könnte man sicher etwas Zeit bei den Testprozeduren sparen...

Ich erlebs täglich: Machen wir noch "schnell" da hier was rein und das dort. Kann ja nicht schwierig sein. Oder? *sugestivfrage* Nein schwierig ist es wohl selten für den Entwickler. Nur "schnell" gibt es für seriöse Entwickler nicht. Ich sag mal gaaaaanz böse: Die PL's (und der Rest) hat einfach schlicht keine Ahnung wie komplex SW-Dev sein kann. Selbst kleinste Dinge können recht Risikobehaftet sein. (Eigentlich brauchen sie das ja auch nicht zu verstehen, aber dann brächten sie den Entwicklern und dessen Aussagen zu vertrauen - aber das tun sie nicht) Oder das: "ach komm, keine grosse Spez, ist ja alles klar!" Ok alles klar... ja ja - genau bis der Kunde die ersten Screens sieht und sagt: Ja aber ich dachte hier könne man die Spalte noch sortieren - Und wo ist überhaupt die Möglichkeit für den Export der Daten...

Die Welt ist und bleibt ungerecht
kaepten