Anti Hyperthreading

CharlieB schrieb:
der kommt dann wahrscheinlich als A64 10.000+ in den Handel,
das würde die Supermarktkäufer sicher zu nem Run auf die Kiste veranlassen :haha:

ne also das was die vorhaben braucht kein Mensch,
ich seh das nach nem Versuch irgendwie ein wenig Medienpräsenz zu gewinnen.


CB

ich sehe durchaus daseinsberechtigung für eine solche Technologie. aber nur wenn es problemlos innerhalb kurzer Zeit aktiviert und deaktiviert werden kann. aber im Grunde genommen braucht man diese Technik nicht ;)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
FischOderAal schrieb:
ich sehe durchaus daseinsberechtigung für eine solche Technologie. aber nur wenn es problemlos innerhalb kurzer Zeit aktiviert und deaktiviert werden kann. aber im Grunde genommen braucht man diese Technik nicht ;)

ich hab das Thema schon vor 5Wochen dort angeschnitten ...
http://www.planet3dnow.de/vbulletin/showthread.php?t=264211

und auch im 3DC darüber diskutiert ...

nach reichlicher Überlegung konnt ich dem nichts mehr Gutes abgewinnen.

1. es ist ein Microsoft patch notwendig,
dh. für mich, dass es ein reines softwarebasiertes skätjuling ist
naja darauf kann ich wirklich getrost verzichten.

Des weiteren wird es eh kaum was bringen,
denn Nicht parallelisierbaren Code KANN MAN NICHT aufteilen.

Ergo bringt das genau bei der anvisierten SoftwareZielgruppe absolut nix.

CB
 
Wie kann man ohne zu wissen wie diese Technik genau funktioniert, Aussagen über den Nutzen und der Performance machen? Glaubst doch nicht im Ernst, AMD würde diese Technik für nichts und wieder nichts einführen, oder doch?

Ausserdem wird diese Technik sehrwohl in Hardware umgesetzt. Und selbst wenn man damit nur wie NEC 7% Mehrleistung erziehlt, so ist das auch nicht zu verachten.
 
Zuletzt bearbeitet:
tja,
wenn man sich schon länger damit beschäftigt dann kann man durchaus Aussagen darüber machen. Es ist ja in dem Sinne keine "Neuigkeit" die heute erst erscheint ;)

Es wird keine hardwarelösung möglichsein die Code jedweder Art auf 2 cPUs verteilt.
Dies ist nicht möglich das kann man schnell beweisen.

Aber nur das würde ja überhaupt einen Nutzen brinegn, denn wenn eine Software SMP ünterstzend gecodet ist, dann spricht sie beide Kerne ja direkt an. Nur gibt es viele Programme die eben nicht auf mehreren CPUs laufen kann und genau für die wird es so keine Möglichkeit geben auf beiden Cores gleichzeitig Berechnungen durchzuführen.

Ich hab an der Uni einige Kollegen und Profs mit der Thematik konfrontiert,
selbst wenn man einen Compiler neu codet der intelligent genug ist, Software dann mehrprozeßfähig zu übersetzen, dann hängt es noch daran, dass dies zu Laufzeiten passieren müsste.
ergo ist das so auch nicht möglich
es gibt noch andere Ansatz/Gesichtspunkte aber ich glaub das ist dann ein wenig Offtopic hier,
das gehört wohl innen anderen Thread..

CB
 
Die Zeit wirds zeigen. Bei uns an der FH gibt es übrigends auch Professoren, die sind sich da nicht so sicher. Zumal es ja von NEC bereits erste Erfolge gibt.

Aber natürlich ist die Erde eine Scheibe und die Sonne dreht sich um die Erde ;)
 
allerdings muss ich CB in dem Punkt der parallelisierbarkeit recht geben. wie will man Aufgaben aufteilen, die aufeinander aufbauen und eben von haus aus NICHT nebeneinander laufen?
 
Wenn AHT was bringt, ist das ja gut. Aber es wäre eher mal an der Zeit, dass man die Programme auf MultiCore Prozessoren optimiert.
 
Das würde die Entwicklung verlangsamen , die Entwickler hätten weniger Gründe Anwendungen auf DC zu optimieren

Und der Performancegewinn wäre auch net so dolle
 
FischOderAal schrieb:
allerdings muss ich CB in dem Punkt der parallelisierbarkeit recht geben. wie will man Aufgaben aufteilen, die aufeinander aufbauen und eben von haus aus NICHT nebeneinander laufen?


es wäre über eine virtual machine möglich, eine art harwdware emulation. einerseitz würde man performance verlieren und andererseits gewinnen. ein logischer prozessor der über eine virtuelle schittstelle die anwendung aufteilt, eine art kaskadierung.

leider kann man nur spekulieren im moment.
 
Zuletzt bearbeitet:
FischOderAal schrieb:
allerdings muss ich CB in dem Punkt der parallelisierbarkeit recht geben. wie will man Aufgaben aufteilen, die aufeinander aufbauen und eben von haus aus NICHT nebeneinander laufen?
Wenn man virtuell die CPU's vereinigt, ist es theoretisch möglich, daß eine singlethreaded Anwendung dann zwar nicht parallel läuft, aber eventuell kann das Proggi dann die doppelten ALU- und FPU-Einheiten etc. nutzen. Es betrachtet einen Dual-Core dann also wie einen einzelnen Core mit doppelter Anzahl an Ausführungseinheiten. Bei Grafikkarten werden doch z.B. auch immer nur die Shader-Einheiten vervielfacht ohne daß weitere Parallelisierung stattfindet (diese wird durch die Anzahl der Pipelines erhöht).

Ich denke, da läßt sich schon einiges mit anstellen.



// edit

Als ob ich's geahnt hätte:

It seems that all AM2 CPUs were outfitted with a support for Reverse-HyperThreading, an architectural change which enables software to think that it is working on a single-core alone. By combining two cores, the company has been able to produce the six IPC "core" that will go head to head against four IPC "core" from Conroe/Merom/WoodCrest combo.

It seems that in certain cases, even an old AMD Athlon 64 3800+ can wipe the floor with Core 2 Duo E6300 CPU.
Quelle: http://www.theinquirer.net/?article=32589

Sicherlich falsch, daß ein 3800+ schneller ist, aber ein 6-fach assoziativer X2 3800+ würde definitiv mehr als nur den E6300 zum Frühstück vernaschen.

Ich bin sehr gespannt.
 
Zuletzt bearbeitet:
Hmmm...wann diese Technologie wohl verfügbar ist?
Vll mit den 4x4 Boards oder erst mit den K8L?
Ich denke erst mit Quadcore wird diese Technologie wirklich interessant werden.
Dazu frage ich mich noch, ob 512Mb Cache(bei den kleinen Modellen) ausreichen werden.

mfg Nakai
 
Naja, die news ist vom inquirer ... ich traue denen nicht so ganz.
Aber wenn das wirklich stimmt, dann bin ich auch sehr gespannt
 
Nakai schrieb:
Hmmm...wann diese Technologie wohl verfügbar ist?
Vll mit den 4x4 Boards oder erst mit den K8L?
[...]



Die soll am 23.7. (also am Conroerelase) durch einen Patch bei allen AM2 DC-CPUs freigeschlatet werden.
 
w0mbat schrieb:
Die soll am 23.7. (also am Conroerelase) durch einen Patch bei allen AM2 DC-CPUs freigeschlatet werden.
Das ist mir aber neu. Will AMD zum 23.7. nicht erst dazu Stellung nehmen bzw. mit ersten Infos rausrücken?
 
Ne, da soll es (angeblich) freigeschaltet werden.
 
Laut diesem Bericht (englische Übersetzung) soll Anti-Hyper-Threading in den AM2-Prozessoren durch einen neuen Prozessortreiber und einen Microsoft-Patch freischaltbar sein und am Tag vor dem offiziellen Conroe-Launch vorgestellt werden.
Quelle
 
Danke für den Link, aber den kannte ich schon. Bei diesem wie auch bei anderen Berichten gehts nur um Spekulationen. Und dann noch - Zitat: "Eine russische Seite will nun erfahren haben..." :hmm:
Nunja, ich denke am 23.07. erfahren wir mehr.
 
es gibt auch zuwenig berichte über die neuen AMD's.

Und weil du es sagst, genau das könnte es ausmachen. Interessant wäre der 3800+ mit 35W TDP.
 
Nakai schrieb:
Hmmm...wann diese Technologie wohl verfügbar ist?
Sofort in dem Moment, wo AMD den Treiber auf die Webseite stellt und Microsoft den Patch verfügbar macht. Soll angeblich am Abend vor dem Conroe-Release passieren.

Super schrieb:
Damit wäre aber AMD wieder vorne
Nein, man würde lediglich im singlethreaded Bereich aufholen, bei multithread wäre weiterhin der Conroe vorn. Und da 4x4 eher was für Q4/06 bzw. Q1/07 ist, kann man 4x4 auch (noch) nicht gegen den Conroe vergleichen.

Ich schätze, das wird AMD's Strategie sein - im singlethread mit dem Anti-HT auf einem Dual-Core und im multithread mit 4x4, sprich zwei Dual-Cores, die selbst dem Kentsfield Paroli bieten. Wie man auf den Benches bei XS gesehen hat, verliert der Kentsfield stark sobald alle 4 Cores um den Systembus konkurrieren. Für jeden Core bleiben dann nur noch knapp 2.1 GB/s I/O Bandbreite (für Speicher und Peripherie und Kommunikation zum anderen Core). Das ist deutlich zu wenig und läßt die Performance merkbar einbrechen (sogar SuperPI 1M mit 4 Instanzen von 20s auf 25s).

http://www.theinquirer.net/?article=32577

Gegen den Kentsfield wird man also mit einem 4x4 System besser dastehen, schätze ich. Da Anti-HT den bisherigen Berichten zufolge aber nur für Cores auf einem Sockel wirken kann, hätte man keinen weiteren Vorteil bei einem 4x4 System (2 Sockel, 2 Dual-Cores). Erst mit einem nativen Quad-Core kann der Anti-HT Treiber die singlethreaded Performance nochmal boosten.

Kann Intel allerdings den Kentsfield früh und günstig bringen, wird es auch 4x4 schwer haben.

Auf jeden Fall hochinteressante Entwicklungen im Moment. Bin gespannt, was letztlich alles bei rum kommt. Für den Endkunden ist aber jeder Konkurrenzkampf beim Preis und bei der Performance ein Gewinn. :)
 
die frage ist nur wie gut AHT wird.
 
xxmartin schrieb:
Sofort in dem Moment, wo AMD den Treiber auf die Webseite stellt und Microsoft den Patch verfügbar macht. Soll angeblich am Abend vor dem Conroe-Release passieren.
[...]



Wenn AHT den wirklich in AM2 implementiert ist. AMD hat nichts bestätigt, was bei AMD aber normal ist.
 
doch es wurde doch schon bestätigt durch das release...
 
Durch welches Relase? Habe ich was verpasst. Wann wurde AHT von AMD bestätigt?
 
@xxmartin

Bis jetzt hat AMD noch nicht gegen den conroe geantwortet, es stehen ihnen aber trotzdem noch paar zusatzpunkte vor der Tür, von verschiedenen Herstellungsverfahren, bis 65NM, Prozessoren mit halbiertem Verbrauch, AntyHyperthreading etc.

Wenn AMD wirklich am Ende wäre und nichts mehr zu bieten hätte, ist klar das sie sich zurückgelehnt haben, warum auch
 
Super schrieb:
[...]
Bis jetzt hat AMD noch nicht gegen den conroe geantwortet,
[...]



Wie auch, den Conroe gibt es noch nicht. :stupid:
 
Bestätigt wurde überhaupt noch nichts. Und einige zweifeln ohnehin, ob das ganze zum aktuellen Stand der Wissenschaft bezüglich Multiskalarität überhaupt schon ansatzweise effizient lösbar ist. Ich sehe das auch noch kritisch, laß mich da aber gern überraschen.

Das Anti-HT aber kommt, ist sicher. Nichts offizielles, aber die Spatzen pfeifen es überall von den Dächern. Was es bringt ist die Frage. Und da der Inq meist einen Funken Wahrheit einbringt und von expect wonder results spricht, wird die Performance sicherlich ganz ok sein. Zwar nur für singlethread, aber in den meisten non-multithreaded Games und Gaming-Benchmarks würde das für einen FX-62/64 wohl gut reichen, um den X6800 nicht davonziehen zu lassen bzw. weiterhin vorn zu bleiben. Wird man sehen müssen.



Super schrieb:
Bis jetzt hat AMD noch nicht gegen den conroe geantwortet, es stehen ihnen aber trotzdem noch paar zusatzpunkte vor der Tür, von verschiedenen Herstellungsverfahren, bis 65NM, Prozessoren mit halbiertem Verbrauch, AntyHyperthreading etc.

Wenn AMD wirklich am Ende wäre und nichts mehr zu bieten hätte, ist klar das sie sich zurückgelehnt haben, warum auch
Jepp, AMD wird auf jeden Fall dran bleiben. Sie selbst kämpfen ja sogar vor Gericht für den offenen Wettbewerb und faire Benchmark-Vergleiche, die den Markt bestimmen. Wäre nicht ganz so glücklich, wenn man sich selbst dann nach den eigenen Prinzipien deklassieren lassen würde. Von daher steht wie schon gesagt mit 65nm, eSiGe, Anti-HT und 4x4 noch einiges ins Haus.

Wenn das Anti-HT wirklich gut funktioniert, sollte man sich zügig daran machen, das ganze in Hardware zu gießen. Wobei auch Intel an einer multiskalaren Lösung in Hardware arbeitet - von daher wird man sich auch da nicht ausruhen können.
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh