News Prescott doch mit 64 Bit?
- Ersteller Tommy
- Erstellt am
- Zur News: Prescott doch mit 64 Bit?
blabla
Banned
- Registriert
- Juni 2003
- Beiträge
- 551
GRAKA0815 schrieb:
Das hat AMD schon desöfteren gesagt und hat auch recht damit. Klar, es ist nicht zu leugnen, dass wenn ein Thread ausgelastet ist, HT auf jeden Fall was bringen würde, mehr aber auch nicht. Durch die kurze Pipeline, großem Cache und super Sprungvorhersage würde HT beim Athlon64 fast überhaupt nix an Performance bringen.
Ausserdem wäre es sicher nicht so einfach, sich das von Intel lizensieren zu lassen. Man hätte noch IBM, aber die gebens sicher auch nicht umsonst her
Bluerock
Commander
- Registriert
- Dez. 2003
- Beiträge
- 2.978
Raid performence und abstuerze das liegt dann wohl an dem Mainboard nicht am Cpu.
Da du so geschwärmt hast wie toll HT ist und das du wieder HT haben willst kann man ja wohl davon ausgehen das du dein A64 3200+ verkaufst weil er kein HT hat oder?
Noch was ich wusste nicht das es den 2.8 ghz auch in der E version gibt.
Naja aber du musst ja das Geld haben.
Bluerock
Da du so geschwärmt hast wie toll HT ist und das du wieder HT haben willst kann man ja wohl davon ausgehen das du dein A64 3200+ verkaufst weil er kein HT hat oder?
Noch was ich wusste nicht das es den 2.8 ghz auch in der E version gibt.
Naja aber du musst ja das Geld haben.
Bluerock
- Registriert
- März 2001
- Beiträge
- 8.193
Bluerock schrieb:
Klar gibt es den. Wurde zusammen mit den 3,4E GHz angekündigt.
Zu HyperThreading an sich: AMD hat sich beim Athlon 64 alle Möglichkeiten offengelassen. Die Northbridge ist so ausgelegt, dass AMD mit der 90nm ohne Probleme DualCore Athlon 64 realisieren kann. Ähnliches hat Intel auch nach HyperThreading ins Auge gefasst - Codename Foxton.
H
hrafnagaldr
Gast
Ein Prescott 2.8 ist nicht wirklich teuer, den gibt es schon ab 172€ laut Geizhals.net, ein A64 3000+ (Tray) fängt ab 185€ an.
Dass RAID Probleme und Co. am Mainboard liegen habe ich ja auch gesagt, genau da ist ja das Problem. AMD sollte wie Intel weiterhin selbst Chipsätze fertigen. Damit würde AMD weiter Punkte gegen Intel gut machen. Aber vor allem die Nforce-Chips sind wunderbare Problemkinder (Speicherkompatibilität, IDE-Treiber, zerstörtes BIOS bei Übertaktversuchen in früheren Chipsatz-Revisionen). Zudem sind die Nforce3 Leistungsmäßig den bisherigen VIA Chips für den A64 Leristungsmäßig ein ganzes Stück unterlegen. VIA macht inzwischen ganz passable Chipsätze aber das gelbe vom Ei ist das noch lange nicht. SiS gibt auch noch, sollen ja auch ganz gut sein aber werden kaum gekauft.
Dass RAID Probleme und Co. am Mainboard liegen habe ich ja auch gesagt, genau da ist ja das Problem. AMD sollte wie Intel weiterhin selbst Chipsätze fertigen. Damit würde AMD weiter Punkte gegen Intel gut machen. Aber vor allem die Nforce-Chips sind wunderbare Problemkinder (Speicherkompatibilität, IDE-Treiber, zerstörtes BIOS bei Übertaktversuchen in früheren Chipsatz-Revisionen). Zudem sind die Nforce3 Leistungsmäßig den bisherigen VIA Chips für den A64 Leristungsmäßig ein ganzes Stück unterlegen. VIA macht inzwischen ganz passable Chipsätze aber das gelbe vom Ei ist das noch lange nicht. SiS gibt auch noch, sollen ja auch ganz gut sein aber werden kaum gekauft.
Tiu
Rear Admiral
- Registriert
- Sep. 2001
- Beiträge
- 5.568
ag3nt schrieb:
War auch nicht als Kritik gedacht, sondern mir ging es um User wie OnSlider (siehe Seite2 ganz oben) die versuchen IA64 mit dem kommenden AMD64 oder CT gleichzusetzen.
@Bluerock
CPU hin CPU her. Eine CPU steht und fällt mit dem Chipsatz.
Erinnern wir uns noch an den VIA Southbridge Bug? Über wieviele Chipsätze wurde der getragen? Oder wie sah es den überhaupt seit dem AMD K7 mit den IRQ´s aus? Welche guten Alternativen hatte man den vor dem nforce/nforce2? SIS oder ALI wollen wir uns doch wirklich nicht antun.
FreakImKäfig
Lt. Junior Grade
- Registriert
- Okt. 2003
- Beiträge
- 276
klar son Intanium2 wäre doch was tolles für mein Desert Combat 
HT ist schon ne ganz super Sache! Ich kann daher Tommy sehr gut verstehen
bin aber schon sehr gespannt auf AMD's Antwort darauf, die DualCore Lösung und natürlich wiederum auf Intels Pendent.
HT ist schon ne ganz super Sache! Ich kann daher Tommy sehr gut verstehen
bin aber schon sehr gespannt auf AMD's Antwort darauf, die DualCore Lösung und natürlich wiederum auf Intels Pendent.
Ich habe auch noch nie etwas davon gehört, das AMD HT als generell unbrauchbar bezeichnet hätte. Das Marketing von AMD hat selbstverständlich HT als "im Moment nicht sinnvoll bezeichnet", da AMD es ja im moment auch nicht liefern kann und es klein reden muss.
Und das es sich lohnen würde hat AMD indirekt selbst bestätigt. Indem sie den Athlon 64 rausgebracht haben. Seine Recheneinheiten funktionieren fast gleich, wie die vom Athlon XP und trotzdem hat er eine stark gesteigerte pro MHz Leistung. AMDs Trick war dabei ganz simpel, man hat einfach die Auslastung der Pipeline erhöht, indem man die Wartezeit zum Speicher verkürzte (durch größeren Cache und Memorycontroller).
Da die Wartezeit zum Speicher, trotz Memorycontroller, immer noch extrem ist, würde sich HT auch hier lohnen (HT nutzt diese Lücken und versucht den negativen Effekt abzumildern)
Da HT nichts anderes ist als SMT (SMP sind Multicores) und dies schon lange im Serverbereich zum Einsatz kommt, glaube ich kaum, dass Lizenzgebühren fällig währen.
Meiner Meinung nach ist HT(SMT) "im Moment" viel besser als ein Multicore(SMP). Aus dem einfachen Grund: Es gibt zu wenige Anwendungen die Multiprozessor-systeme unterstützen und HT ist Transistormäßig viel billiger.
Für Multitasking reicht SMT vollkommen (sieht man ja an den ganzen Posts hier)
Ein paar Encoder unterstützen wohl Multiprozessor-systeme (und somit auch SMT), aber die paar rechtvertigen nicht die zusätzlichen Transistoren, die für SMP nötig währen.
Bis Spiele und Programme was mit SMT/SMP anfangen können wirds noch ne Zeit lang dauern, schließlich müssen die Programme fast komplett umgeschrieben werden.
Simples HT wird wohl die Zeit überbrücken, bis eine kritische Masse erreicht ist und massiv auf Multiprozessor Lösungen gesetzt wird (egal welche) (Meine Meinung, braucht ihr nicht zu teilen)
Aber alles kommt anders als man denkt
Und das es sich lohnen würde hat AMD indirekt selbst bestätigt. Indem sie den Athlon 64 rausgebracht haben. Seine Recheneinheiten funktionieren fast gleich, wie die vom Athlon XP und trotzdem hat er eine stark gesteigerte pro MHz Leistung. AMDs Trick war dabei ganz simpel, man hat einfach die Auslastung der Pipeline erhöht, indem man die Wartezeit zum Speicher verkürzte (durch größeren Cache und Memorycontroller).
Da die Wartezeit zum Speicher, trotz Memorycontroller, immer noch extrem ist, würde sich HT auch hier lohnen (HT nutzt diese Lücken und versucht den negativen Effekt abzumildern)
Da HT nichts anderes ist als SMT (SMP sind Multicores) und dies schon lange im Serverbereich zum Einsatz kommt, glaube ich kaum, dass Lizenzgebühren fällig währen.
Meiner Meinung nach ist HT(SMT) "im Moment" viel besser als ein Multicore(SMP). Aus dem einfachen Grund: Es gibt zu wenige Anwendungen die Multiprozessor-systeme unterstützen und HT ist Transistormäßig viel billiger.
Für Multitasking reicht SMT vollkommen (sieht man ja an den ganzen Posts hier)
Ein paar Encoder unterstützen wohl Multiprozessor-systeme (und somit auch SMT), aber die paar rechtvertigen nicht die zusätzlichen Transistoren, die für SMP nötig währen.
Bis Spiele und Programme was mit SMT/SMP anfangen können wirds noch ne Zeit lang dauern, schließlich müssen die Programme fast komplett umgeschrieben werden.
Simples HT wird wohl die Zeit überbrücken, bis eine kritische Masse erreicht ist und massiv auf Multiprozessor Lösungen gesetzt wird (egal welche) (Meine Meinung, braucht ihr nicht zu teilen
)Aber alles kommt anders als man denkt
AMD hat beim K8 kräftig am Design gearbeitet und optimiert (s. z.B. x86-secrets.com)
Das Gerede vom 'aufgebohrten' K7 kommt wohl aus der Intel-Propaganda-Abteilung.
Intel hat bereits früh gemerkt, das HT (SMP!?) beim Netburst Design 'Perlen vor die Säue geworfen' ist. HT wirkt nur bei wenigen Programmroutinen vorteilhaft, da die CPU eh ständig unter dem Mangel an Datenzufuhr leidet wg. zu hohem Takt.. Aber Intel will ja GHz ohne Ende...
HT im Einfachdesign (s.Northwood) ist sinnvoll, aber die Entwicklung für AMD wohl zu teuer. Komplexes HT (s. Prescott) ist aber Blödsinn im Vergleich zu echten Dual-Core CPUs.
AM verzichtet daher aus Kostengründen auf das (eh durch den Prescott überholte) einfach-HT und setzt auf die 65 nm/45 nm Fertigung der Fab36. 2006 kann AMD eh Transistoren ohne Ende auf den DIE packen und Dual-Core werden dann eh Standart.
Programmtechnisch sind aber echte Multicore CPUs und HTr-Verbunde (Hyperlink) aus Single-CPUs identisch, sodaß bis 2006 die Softwareentwickler Zeit genug für echte Parallel-Software haben.
Das Gerede vom 'aufgebohrten' K7 kommt wohl aus der Intel-Propaganda-Abteilung.
Intel hat bereits früh gemerkt, das HT (SMP!?) beim Netburst Design 'Perlen vor die Säue geworfen' ist. HT wirkt nur bei wenigen Programmroutinen vorteilhaft, da die CPU eh ständig unter dem Mangel an Datenzufuhr leidet wg. zu hohem Takt.. Aber Intel will ja GHz ohne Ende...
HT im Einfachdesign (s.Northwood) ist sinnvoll, aber die Entwicklung für AMD wohl zu teuer. Komplexes HT (s. Prescott) ist aber Blödsinn im Vergleich zu echten Dual-Core CPUs.
AM verzichtet daher aus Kostengründen auf das (eh durch den Prescott überholte) einfach-HT und setzt auf die 65 nm/45 nm Fertigung der Fab36. 2006 kann AMD eh Transistoren ohne Ende auf den DIE packen und Dual-Core werden dann eh Standart.
Programmtechnisch sind aber echte Multicore CPUs und HTr-Verbunde (Hyperlink) aus Single-CPUs identisch, sodaß bis 2006 die Softwareentwickler Zeit genug für echte Parallel-Software haben.
Dunkeltier
Lieutenant
- Registriert
- Nov. 2002
- Beiträge
- 531
Wie oft denn noch, die Dual-Core Lösung wird aus Kostengründen nur für Workstations (oder Server u.ä.), aber nicht gerade für den Mainstreammarkt erscheinen. Aber das scheinen einige nicht begreifen zu wollen. Im übrigen heißt es Standard (ohne t!). Lernt das endlich mal, so schwer kanns doch nicht sein.
