Seite 1 von 29 1234511 ... LetzteLetzte
Ergebnis 1 bis 25 von 720
  1. Beitrag #1
    Themenstarter
    Admiral
    Special
    Admiral

    Registriert seit
    02.05.2009
    Beiträge
    1.642
    Danke
    76
    Gedankt 36 Mal für 6 Themen

    Intel Haswell - AVX2 | FMA3 | 22nm

    Intel Haswell (Sockel 1150) Gerüchte + FAQ + Infos [Sammelthread]



    Facts:

    Mit Haswell steht im nächsten Jahr eine neue Intel-Prozessorengeneration für das Mainstream-Segment an.
    Der Prozessor wird zwar wieder in 22 nm gefertigt, besitzt diesmal aber im Vergleich zu Ivy Bridge über eine neue Mikroarchitektur.
    Im Fokus steht diesmal vor allem die Grafikeinheit, während sich beim reinen Prozessorteil hinsichtlich der Taktraten fast nichts tut.
    Dort soll neben der erhöhten Anzahl an Ausführungseinheiten auch noch eine völlig neue Architektur zum Einsatz kommen.
    Außerdem können die alten Mainboards (Sockel 1155, Intel Sandy und Ivy Bridge) nicht mehr eingesetzt werden, da auf einen neuen Sockel LG1150 gesetzt wird.

    Voraussichtlicher Release: Q2/2013
    Fertigung: 22 nm (3D-Transistoren)
    TDP: 84 W
    Grafikeinheit: Intel HD 4600
    Sockel: LGA 1150
    Chipsätze: Z87, H87 und B85 sowie Q87, Q85 und H81 ("Lynx Point"-Chipsätze)
    Versionen: K = Freier Multiplikator, S = Stromspar, T = Noch mehr Stromspar/Niedrigere TDP (+Takt), ULV = Ultra Low Voltage (Stromspar + architektonische Änderung)


    Änderungen und Verbesserungen:

    Chipset:

    - "Lynx Point"-Chipsätze: Z87, H87 und B85 sowie Q87, Q85 und H81
    - Fertigung in 32nm statt 65nm, also stromsparender
    - 4 native USB-3.-0-Anschlüsse
    - Bis zu 6 native SATA-6GB/s-Ports
    - Mehr Details im Sammelthread: http://www.hardwareluxx.de/community...85-902183.html






    Core + System-Agent:

    - 22nm aber neue Mikroarchitektur
    - Multi-Chip-Packages (MCP) vereint Chipsatz und Prozessor auf einem Träger, sowie On Package Interface (OPI), das als eine angepasste Version des DMI den Chipsatz mit dem Prozessor verbindet
    - Bei erreichen des TJmax throttelt Chipset nun auch, auch wenn CPU diesen erreicht
    - Neue Stromsparmodi: Für Haswell: C0, C2E, C7 und für Haswell-UT: Zusätzlich C8, C9 und C10
    - BCLK („Baseclock“) kann auch auf 24 abesenkt werden, ermöglicht niedrigere Taktraten im Idle und somit die Verbesserung der Effizienz bei Teillast und Idle
    - Architektonische Änderungen: ULT Prozessoren besizten kein PCI-Express(-3.0)-Support, kein Overclocking usw.
    - Vielleicht bei den Modellen für Enthusiasten BLCK Straps
    - Speicherunterstützung mit bis zu DDR3-1600










    iGPU (HD 4600):

    - Unterstützung von DirectX 11.1, OpenCL 1.2 sowie OpenGL 4.0
    - Vermutliche Unterstützung der 4K-Auflösung (4.096 Pixel in der Breite)
    - Die iGPUs werden intern wie bisher auch als GT1 (6-10 EUs) und GT2 (26-30 EUs) benannt, hinzu kommt bei Haswell als neue Lösung erstmals GT3 (40 EUs)
    - Die neue iGPU aller (!) Haswell Desktop Prozessoren wird vermutlich die HD 4600 sein – die bisher als GT2 gehandelte Einheit mit 20 EUs
    - Statt bisher 16 Execution Units nun also 20 oder sogar 40, wobei die GT3-Lösung mit 40 EUs nach bisherigen Erkenntnissen nur im mobilen Segment genutzt werden soll
    - Erweiterte Codec-Unterstützung für De- und Enkodierung von Videos, sowie eine eigenständige Video Quality Engine (VQE)
    - Weitergeführte Leistungssteigerungen sowie Energiesparmaßnahmen
















    Haswell Prozessoren für den Desktop:



    Haswell offizielle Testberichte


    Geändert von Duplex (26.06.2013 um 17:41 Uhr)

  2. Die folgenden 8 Benutzer sagen Danke zu Duplex für diesen nützlichen Beitrag:

    Bobo_Oberon (25.09.2011), FredD (25.09.2011), Lexxington (26.09.2011), Opteron (02.10.2011), SPawner (25.09.2011), Stryki (25.09.2011), Woerns (26.09.2011), yasu (26.09.2011)

  3. Beitrag #2
    Redaktion
    Redaktion
    Avatar von Opteron
    Registriert seit
    13.08.2002
    Beiträge
    20.435
    Danke
    302
    Gedankt 1.727 Mal für 196 Themen
    Gerüchte:

    Franklin Zhou, a retired chip architect and now a fellow systems integrator for our Taipei farms mentioned an interesting theory on the upcoming Haswell microarchtecture. The giveaway was Intel's statement that the microarchitecture uses an "entirely new cache scheme" which would indicate that the decoders will be at the far front of the data pipe and that the L0 cache will be one huge cache (most likely in the megabytes), completely removing the need for any code cache. The L0 cache will store predecoded and fused instructions of fixed length. The TLB will be entirely different since the fixed length instructions does not have a 1:1 equivalent addressing to physical memory.

    What does it all mean? Well for one, the x86 decoder latency is vastly reduced since medium and even large loops can run inside the L0 cache. It also means that if the L0 cache is designed well enough, that is, if the hit ratio is well above 99%, then the arch need only a few decoders (maybe just 4) to satisfy the needs of an equivalent of two or more cores without any performance hit, saving chip real estate (expect the decoders to have long pipes).

    The L0 cache could be multi-banked and multi-ported (for each bank) so that several simultaneous accesses are possible. This means that there will be several schedulers feeding several short decoders and execution units. There could also be several small caches (2K perhaps) feeding off the L0, one for each "core", that way, the schedulers won't starve the L0 cache read bandwidth. There will be no clear distinction as to how many units will make a single "core", instead there will be banks of EUs that together will be able to simultaneously process up to eight threads by default. Notice I said "up to", that's because the scheme allows for "dynamic threading" where the system can process a smaller number of threads to increase the IPC per thread.

    Funny thing is that this theoretical arch sounds so similar to CMT but taken a level higher. I would like to think of it as a "fat CMT"...
    http://semiaccurate.com/forums/showt...?t=4218&page=5


  4. Beitrag #3
    Lt. Commander
    Lt. Commander

    Registriert seit
    09.03.2009
    Beiträge
    139
    Danke
    0
    Gedankt 0 Mal für 0 Themen
    Na dann freuen wir uns alle auf neue lange Diskussionen was ein echter Core ist, und wer mehr Cores hat :-()

  5. Beitrag #4
    Grand Admiral
    Special
    Grand Admiral
    Avatar von LoRDxRaVeN
    • Mein System
      Notebook
      Modell: Lenovo Thinkpad Edge 11
      Desktopsystem
      Prozessor: Phenom II X4 955 C3
      Mainboard: Gigabyte GA-MA790X-DS4
      Kühlung: Xigmatek Thor's Hammer + Enermax Twister Lüfter
      Arbeitsspeicher: 4 x 1GB DDR2-800 Samsung
      Grafikkarte: Sapphire HD4870 512MB mit Referenzkühler
      Display: 22'' Samung SyncMaster 2233BW 1680x1050
      Festplatte(n): Hitachi Deskstar 250GB, Western Digital Caviar Green EADS 1TB
      Optische Laufwerke: Plextor PX-130A, Plextor Px-716SA
      Soundkarte: onboard
      Gehäuse: Aspire
      Netzteil: Enermax PRO82+ II 425W ATX 2.3
      Betriebssystem(e): Windows 7 Professional Studentenversion
      Browser: Firefox siebenunddreißigsttausend
      sysProfile: System bei sysProfile

    Registriert seit
    20.01.2009
    Ort
    Oberösterreich - Studium in Wien
    Beiträge
    3.646
    Danke
    38
    Gedankt 18 Mal für 1 Thema
    Hört sich zum Teil nach dem sagenumwogenen Reverse-Hyperthreading an - wenn die Sache dynamisch von Statten geht
    Die grauenhaftesten Rechtschreibfehler in deutschsprachigen Hardwareforen:
    Falsch: Standart Richtig: Standard
    Falsch: Tackt Richtig: Takt
    Falsch: einzigste Richtig: einzige
    Falsch: am Markt aufschlagen Richtig: auf den Markt kommen/erscheinen (etc.)

  6. Beitrag #5
    Grand Admiral
    Special
    Grand Admiral
    Avatar von gruffi

    Registriert seit
    08.03.2008
    Beiträge
    2.890
    Danke
    68
    Gedankt 0 Mal für 0 Themen
    Naja, im Grunde ist die FPU in Bulldozer ja schon sowas wie "Reverse-Hyperthreading".


    There will be no clear distinction as to how many units will make a single "core", instead there will be banks of EUs that together will be able to simultaneously process up to eight threads by default.
    Das hört sich in der Tat sehr nach CMT an, nur halt nicht wie in Bulldozer mit 2 Threads, sondern mit 8 Threads. Auch wenn "banks of" nicht direkt danach klingt, interessant wäre mal ein Design, wo wirklich alle EUs eines "Kerns" einem Thread zur Verfügung gestellt werden können. Halt so wie die FPU in Bulldozer, nur zusätzlich auch die Integer Einheiten. Klingt auf jeden Fall spannend.

    This means that there will be several schedulers feeding several short decoders and execution units.
    Sollten die (short) Decoder nicht die Scheduler füttern und nicht umgekehrt?


    Die L0 Geschichte klingt aber recht seltsam. Ziemlich viel Aufwand für einen Codecache, der eine weitere Stufe fürs Decoding bedeutet (Predecoding) und hohe Latenzen aufgrund der Grösse besitzt? Das würde sich ja maximal lohnen, wenn man ständig den gleichen Code verarbeitet (Multithreading: yep, Multitasking: nope) oder grosse Schleifen hat, die nicht in bisherige uOp-Caches passen. Und auch nur dann, wenn man die Fetch- und Decoder-Latenzen verringern kann. Klingt für mich irgendwie nach Murks. Ein uOp-Cache ist vergleichsweise simpel und fängt das wichtigste schon recht gut ab, Schleifen, die viel Performance fressen.
    Don't reinvent the wheel ... unless you plan on learning more about wheels.

    Diese Nachricht wird nicht angezeigt, da sich y33H@ auf deiner Ignorier-Liste befindet.

  7. Beitrag #6
    Redaktion
    Redaktion
    Avatar von Opteron
    Registriert seit
    13.08.2002
    Beiträge
    20.435
    Danke
    302
    Gedankt 1.727 Mal für 196 Themen
    Zitat Zitat von gruffi Beitrag anzeigen
    Naja, im Grunde ist die FPU in Bulldozer ja schon sowas wie "Reverse-Hyperthreading".
    ?? Nö, das ist SMT pur, 2 Threads laufen auf einem Unit.
    Solange man keinen 256b AVX Befehl explizit angibt, wandelt da keine Logik 2x128b automatisch in 256b um. Wäre sowieso ne blöde Idee, da langsamer.


  8. Beitrag #7
    Grand Admiral
    Special
    Grand Admiral
    • Mein System
      Notebook
      Modell: Lenovo Thinkpad X60s
      Desktopsystem
      Prozessor: Phenom II 955 BE
      Mainboard: DFI LanParty DK 790FXB-M3H5
      Kühlung: Noctua NH-U12P
      Arbeitsspeicher: 4GB OCZ Platinum DDR1600 7-7-7 @ 1333 6-6-6
      Grafikkarte: Radeon 4850 1GB
      Festplatte(n): Western Digital Caviar Black 1TB
      Netzteil: Enermax Modu 525W
      Betriebssystem(e): Linux, Vista x64
      Browser: Firefox 3.5

    Registriert seit
    14.07.2006
    Beiträge
    3.912
    Danke
    22
    Gedankt 21 Mal für 5 Themen
    Klingt dennoch lustig...
    Hatte der P4 nicht was ähnliches?
    Also eine art Trace-Cache der vordekodierte Befehle speicherte?
    Real Programmers always confuse Christmas and Halloween because OCT 31 == DEC 25 !
    Andrew Rutherford (andrewr@ucs.adelaide.edu.au)

    Um ein tadelloses Mitglied einer Schafherde sein zu können, muss man vor allem ein Schaf sein.
    Albert Einstein

  9. Beitrag #8
    Grand Admiral
    Special
    Grand Admiral
    Avatar von gruffi

    Registriert seit
    08.03.2008
    Beiträge
    2.890
    Danke
    68
    Gedankt 0 Mal für 0 Themen
    Zitat Zitat von Opteron Beitrag anzeigen
    ?? Nö, das ist SMT pur, 2 Threads laufen auf einem Unit.
    Nö, das sind Units (2x FMAC + 2x Packed Integer), die für 2 Threads dimensioniert wurden, bei Bedarf aber einem Thread zur Verfügung gestellt werden können. Halt das Prinzip von "Reverse-Hyperthreading" oder "Anti-Hyperthreading".

    Zitat Zitat von Opteron Beitrag anzeigen
    Solange man keinen 256b AVX Befehl explizit angibt, wandelt da keine Logik 2x128b automatisch in 256b um.
    Wieso sollte man auch?
    Geändert von gruffi (04.10.2011 um 12:57 Uhr)
    Don't reinvent the wheel ... unless you plan on learning more about wheels.

    Diese Nachricht wird nicht angezeigt, da sich y33H@ auf deiner Ignorier-Liste befindet.

  10. Beitrag #9
    Redaktion
    Redaktion
    Avatar von Opteron
    Registriert seit
    13.08.2002
    Beiträge
    20.435
    Danke
    302
    Gedankt 1.727 Mal für 196 Themen
    Zitat Zitat von gruffi Beitrag anzeigen
    Nö, das sind Units (2x FMAC + 2x Packed Integer), die für 2 Threads dimensioniert wurden, bei Bedarf aber einem Thread zur Verfügung gestellt werden können. Halt das Prinzip von "Reverse-Hyperthreading" oder "Anti-Hyperthreading".
    Nö, das ist SMT pur. Wenn Auf nem Intel nur 1 Thread läuf hat er doch auch alles zur Verfügung. 3x INT, 3xFPU und und und. Simples, normales SMT.

    ReveresHTh war damals ne Technik µOps an nen anderen Kern auszulagern. Was nun ein Kern ist, ist beim Bulldozer bekanntlich die große Frage. Wenns nun 2 eigene, getrennte FPUs gäbe, dann würde ich Deine Sichtweise teilen. Die gibts aber nicht, es gibt nur eine FPU mit einem einzigen Scheduler, von daher seh ich das als SMT an. Ob da nun 2 FMACs hinter dem Scheduler kommen, oder nur eine, oder 4, ist wurst, es ist eine FPU Unit. AMD siehts ja auch genauso, das rote ist SMT:



  11. Beitrag #10
    Grand Admiral
    Special
    Grand Admiral
    Avatar von gruffi

    Registriert seit
    08.03.2008
    Beiträge
    2.890
    Danke
    68
    Gedankt 0 Mal für 0 Themen
    Zitat Zitat von Opteron Beitrag anzeigen
    Nö, das ist SMT pur. Wenn Auf nem Intel nur 1 Thread läuf hat er doch auch alles zur Verfügung. 3x INT, 3xFPU und und und. Simples, normales SMT.
    Nö, wie ich schon sagte, das ist vom Prinzip her "Reverse-Hyperthreading", wenn die Dimensionierung für mehr als einen Thread ausgelegt ist, aber dennoch alle EUs einem Thread zur Verfügung gestellt werden können. Und genau so wurde ja das Cluster-Design in Bulldozer konzipiert, speziell eben die Flex FPU. Wie Intel seine Architekturen geplant hat, kann ich dir nicht sagen. Fakt ist aber, sie hatten mit der Core Architektur die aktuellen EUs ja schon vor Hyperthreading. Und da lief lediglich ein Thread pro Kern. Was du als Kern bezeichnet, ist letztendlich aber völlig belanglos. Das hängt einfach vom Design ab. Ebenso die Scheduler. Ob die getrennt sind wie bei den Stars Int Pipes oder ein Unified Scheduler wie bei einem Bulldozer Int Cluster, ist einfach nur ein Detail der Implementierung. SMT hat jedenfalls eine andere Aufgabe, nämlich mit zusätzlichen Threads die vorhandenen EUs besser auszulasten. Und davon findet man definitiv nichts in Bulldozer.
    Don't reinvent the wheel ... unless you plan on learning more about wheels.

    Diese Nachricht wird nicht angezeigt, da sich y33H@ auf deiner Ignorier-Liste befindet.

  12. Beitrag #11
    Redaktion
    Redaktion
    Avatar von Opteron
    Registriert seit
    13.08.2002
    Beiträge
    20.435
    Danke
    302
    Gedankt 1.727 Mal für 196 Themen
    Zitat Zitat von gruffi Beitrag anzeigen
    SMT hat jedenfalls eine andere Aufgabe, nämlich mit zusätzlichen Threads die vorhandenen EUs besser auszulasten. Und davon findet man definitiv nichts in Bulldozer.
    Für mich ist das eindeutig die FPU. Erst mit 2 Threads wird die richtig ausgelastet.
    Aber nun gut, haben wir halt wieder andere Ansichten. Ich hab Dir ne AMD Folie gezeigt, auf der gross und deutlich SMT steht, Du aber schön ignorierst, was soll man da noch weiter sagen.
    Bleib gerne bei Deiner Meinung, ich bleib bei der von AMD ;-)


  13. Beitrag #12
    Grand Admiral
    Special
    Grand Admiral
    Avatar von gruffi

    Registriert seit
    08.03.2008
    Beiträge
    2.890
    Danke
    68
    Gedankt 0 Mal für 0 Themen
    Zitat Zitat von Opteron Beitrag anzeigen
    Für mich ist das eindeutig die FPU. Erst mit 2 Threads wird die richtig ausgelastet.
    Dann widersprichst du aber den Ingenieuren. Und die werden es wohl besser wissen. Ich kann mich noch dunkel an deren Worte erinnern (Chuck Moore Analyst Day 2009?), als man sagte, dass die FPU für 2 Threads dimensioniert wäre und die Ressourcen für einen Thread eigentlich überdimensioniert wären. Das passt jedenfalls nicht zum Prinzip von SMT.

    Zitat Zitat von Opteron Beitrag anzeigen
    Aber nun gut, haben wir halt wieder andere Ansichten. Ich hab Dir ne AMD Folie gezeigt, auf der gross und deutlich SMT steht, Du aber schön ignorierst, was soll man da noch weiter sagen.
    Was soll ich denn mit so einer dahingeworfenen Folie anfangen? Ich sehe jedenfalls keinen Bezug. Und was erwartest du denn? Dass AMD auf die Folie "Reverse-Hyperthreading" schreibt? Wenn es nach dir ginge, hätten alle bisherigen AMD Prozessoren SMT oder wie? Schliesslich haben die auch alle einen L2. So wie ich das sehe, geht's da lediglich darum, wie die Threadverarbeitung in den einzelnen Stufen ausschaut und wie das mit gängigen Multithreading Konzepten vergleichbar ist. Und natürlich werden von mehreren Threads gemeinsam genutzte Ressourcen auch bei einer SMT Implementierung verwendet. Das heisst doch aber nicht, dass Bulldozer das SMT Konzept verfolgt. Du betrachtest das Thema einfach vom falschen Standpunkt aus. Ein Thread oder mehrere Threads, die Zugriff auf die gleichen Ressourcen haben, schliesst sich doch nicht aus. Wir betrachteten aber lediglich einen Thread. Und so wie die Flex FPU dann arbeitet, entspricht das eben dem Prinzip von "Reverse-Hyperthreading", weil die Ressourcen für mehr als einen Thread ausgelegt sind.
    Don't reinvent the wheel ... unless you plan on learning more about wheels.

    Diese Nachricht wird nicht angezeigt, da sich y33H@ auf deiner Ignorier-Liste befindet.

  14. Beitrag #13
    Grand Admiral
    Special
    Grand Admiral
    Avatar von Dresdenboy

    Registriert seit
    28.10.2003
    Ort
    Berlin
    Beiträge
    2.692
    Danke
    25
    Gedankt 68 Mal für 2 Themen
    Zitat Zitat von gruffi Beitrag anzeigen
    Dann widersprichst du aber den Ingenieuren. Und die werden es wohl besser wissen. Ich kann mich noch dunkel an deren Worte erinnern (Chuck Moore Analyst Day 2009?), als man sagte, dass die FPU für 2 Threads dimensioniert wäre und die Ressourcen für einen Thread eigentlich überdimensioniert wären. Das passt jedenfalls nicht zum Prinzip von SMT.
    Was ist denn das Prinzip? Es geht doch eher um geeignete Kompromisse.

    Mal unabhängig davon ist die FPU mit mehreren Zyklen Latenz bei allen Befehlen eine gute Kandidatin dafür, per SMT die Befehle eines zweiten Threads hineinzumischen.
    Mein Bulldozer-Blog
    Twitter Feed @Dresdenboy.

    Ein bisschen Coding-Nostalgie: Erste Marching-Cubes-Implementation in einem 3k Intro

    Computing Nostalgia + History: C64, Am386DX40, Cx486, Amiga 1200, K6, K6-2, XP, A64, A64 X2, Athlon II X4

  15. Beitrag #14
    Grand Admiral
    Special
    Grand Admiral
    Avatar von gruffi

    Registriert seit
    08.03.2008
    Beiträge
    2.890
    Danke
    68
    Gedankt 0 Mal für 0 Themen
    Zitat Zitat von Dresdenboy Beitrag anzeigen
    Mal unabhängig davon ist die FPU mit mehreren Zyklen Latenz bei allen Befehlen eine gute Kandidatin dafür, per SMT die Befehle eines zweiten Threads hineinzumischen.
    Ich denke, du wirfst hier zwei Sachen durcheinander. SMT mag bei Cache helfen, Latenzen zu verstecken, nicht aber bei Befehlslatenzen. Befehlslatenzen definieren sich ja hauptsächlich dadurch, wie lange eine Instruktion braucht, bis sie von den EUs verarbeitet wurde. Genau dann bringt dir SMT rein gar nichts, egal wie gross die Latenz ist. SMT bringt erst dann etwas, wenn EUs frei sind. Oder anders formuliert, je niedriger die Befehlslatenzen, umso besser für SMT, weil die EUs dann schneller wieder frei sind und von anderen Threads genutzt werden können. Hohe Befehlslatenzen sind eher kontraproduktiv für SMT.
    Don't reinvent the wheel ... unless you plan on learning more about wheels.

    Diese Nachricht wird nicht angezeigt, da sich y33H@ auf deiner Ignorier-Liste befindet.

  16. Beitrag #15
    Themenstarter
    Admiral
    Special
    Admiral

    Registriert seit
    02.05.2009
    Beiträge
    1.642
    Danke
    76
    Gedankt 36 Mal für 6 Themen
    Etwas neues von Haswell

    http://www.chiphell.com/thread-308643-1-1.html






    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken Klicke auf die Grafik für eine größere Ansicht 

Name:	1.jpg 
Hits:	2339 
Größe:	326,5 KB 
ID:	24079   Klicke auf die Grafik für eine größere Ansicht 

Name:	2.jpg 
Hits:	2358 
Größe:	346,4 KB 
ID:	24080   Klicke auf die Grafik für eine größere Ansicht 

Name:	3.jpg 
Hits:	2361 
Größe:	307,6 KB 
ID:	24081   Klicke auf die Grafik für eine größere Ansicht 

Name:	4.jpg 
Hits:	2370 
Größe:	314,0 KB 
ID:	24082   Klicke auf die Grafik für eine größere Ansicht 

Name:	5.jpg 
Hits:	2370 
Größe:	399,6 KB 
ID:	24083  

    Klicke auf die Grafik für eine größere Ansicht 

Name:	6.jpg 
Hits:	2350 
Größe:	234,6 KB 
ID:	24084  

  17. Beitrag #16
    Themenstarter
    Admiral
    Special
    Admiral

    Registriert seit
    02.05.2009
    Beiträge
    1.642
    Danke
    76
    Gedankt 36 Mal für 6 Themen
    Laut Wiki hat Haswell "1MB L2 cache per core and up to a 32MB L3 cache for the Extreme Edition and Xeon."

    400% mehr L2 Cache & 60% mehr L3 Cache als Sandy Bridge-E

    Der L2 Cache wird im vergleich zum "Core2" Cache Design aber richtig aufgepumpt, bisher hat Intel seit Core2 bis Sandy Bridge immer die gleiche L2 Größe gehabt, das war immer sehr schnell.
    Der einzige Nachteil könnte die Latenzen betreffen, aber Faktor4 Steigerung ist schon heftig da muss sich Intel etwas gutes ausgedacht haben

    http://en.wikipedia.org/wiki/Haswell...rchitecture%29
    Geändert von Duplex (04.12.2011 um 15:01 Uhr)

  18. Beitrag #17
    Redaktion
    Redaktion
    Avatar von Opteron
    Registriert seit
    13.08.2002
    Beiträge
    20.435
    Danke
    302
    Gedankt 1.727 Mal für 196 Themen
    Schau mal in der Änder-Historie des Bulldozer-Wikieintrags nach, wieviel Cache der Chip schon Mal hatte. Wiki als Quelle bei solchen hochspekulativen Sachen, wie unfertige Chips im Planungsstadium ist Blödsinn hoch 3.
    Da ist das Gerüchte mit dem Transactional Memory 10x glaubhafter.


  19. Beitrag #18
    Fleet Captain
    Special
    Fleet Captain
    Avatar von Lepus
    • Mein System
      Notebook
      Modell: Alienware M17x R4
      Prozessor: Intel Core i7-3820M Single Thread @ max 4,1GHz
      Arbeitsspeicher: 2x4GB Mushkin 1600MHz (ULV)
      Grafikkarte: Dell AMD HD 7970M
      Display: 17,3" FHD
      Festplatte(n): Crucial m4 256Gb mSata
      Optische Laufwerke: HL-DT-ST DVDRW/BR-ROM
      Soundkarte: Creative Sound Blaster Recon 3Di / HM77
      Gehäuse: Alienware M17x R4
      Netzteil: Dell 240W
      Betriebssystem(e): Windows 8
      Browser: Opera

    Registriert seit
    14.08.2009
    Ort
    München
    Beiträge
    288
    Danke
    5
    Gedankt 0 Mal für 0 Themen
    Und? Läuft!

  20. Beitrag #19
    Themenstarter
    Admiral
    Special
    Admiral

    Registriert seit
    02.05.2009
    Beiträge
    1.642
    Danke
    76
    Gedankt 36 Mal für 6 Themen
    Zitat Zitat von Opteron Beitrag anzeigen
    Wiki als Quelle bei solchen hochspekulativen Sachen, wie unfertige Chips im Planungsstadium ist Blödsinn hoch 3.
    Da ist das Gerüchte mit dem Transactional Memory 10x glaubhafter.
    Die L2 Größe mit 1MB pro Core glaube ich auch nicht wirklich, bisher hat man immer auf schnellen 256KB L2 gesetzt, warum sollte man den durch einen neuen ersetzen?

  21. Beitrag #20
    Admiral
    Special
    Admiral
    Avatar von FredD

    Registriert seit
    25.01.2011
    Beiträge
    1.336
    Danke
    115
    Gedankt 5 Mal für 2 Themen
    Zitat Zitat von Duplex Beitrag anzeigen
    Die L2 Größe mit 1MB pro Core glaube ich auch nicht wirklich, bisher hat man immer auf schnellen 256KB L2 gesetzt, warum sollte man den durch einen neuen ersetzen?
    "New Cache Design" heißt so viel wie "Überraschung"

    EDIT:
    Ich tippe übrigens auf so etwas wie "Bulldozer done right", jedoch etwas bodenständiger, siehe Nehalem.
    Geändert von FredD (07.12.2011 um 12:48 Uhr)

  22. Beitrag #21
    Grand Admiral
    Special
    Grand Admiral
    Avatar von Dresdenboy

    Registriert seit
    28.10.2003
    Ort
    Berlin
    Beiträge
    2.692
    Danke
    25
    Gedankt 68 Mal für 2 Themen
    Transactional Memory wird auf beiden Seiten schon fleißig patentiert.

    Das neue Cache-Design (für Gather-Operationen) wird vielleicht auf viele parallele, aber nicht so breite Bankzugriffe optimiert. Damit aber auch ausreichend Daten dafür da sind, sollten die schnelleren Caches größer sein, damit beim Gathering nicht ein paar Zugriffe quer ins langsame DRAM feuern.
    .
    EDIT :
    .

    Zitat Zitat von FredD Beitrag anzeigen
    Ich tippe übrigens auf so etwas wie "Bulldozer done right", jedoch etwas bodenständiger, siehe Nehalem.
    So etwas wie Cluster kann ich mir auch vorstellen. Intel's Gonzalez arbeitet auch an flexiblen Ressourcenzuordnungen (z.B. 2 Cluster für einen Thread).

    Aber ein "Bulldozer done right" erfordert ersteinmal einen "Bulldozer done wrong" Der jetzige BD1 ist aber nicht "falsch", sondern hat eher nur zu wenig von dem, was AMD schon angedacht hat. Hier kann man die Probleme im Management, in knappen Ressourcen, in Sackgassen usw. suchen.
    Mein Bulldozer-Blog
    Twitter Feed @Dresdenboy.

    Ein bisschen Coding-Nostalgie: Erste Marching-Cubes-Implementation in einem 3k Intro

    Computing Nostalgia + History: C64, Am386DX40, Cx486, Amiga 1200, K6, K6-2, XP, A64, A64 X2, Athlon II X4

  23. Beitrag #22
    Admiral
    Special
    Admiral
    Avatar von FredD

    Registriert seit
    25.01.2011
    Beiträge
    1.336
    Danke
    115
    Gedankt 5 Mal für 2 Themen
    Zitat Zitat von Dresdenboy Beitrag anzeigen
    Aber ein "Bulldozer done right" erfordert ersteinmal einen "Bulldozer done wrong" Der jetzige BD1 ist aber nicht "falsch", sondern hat eher nur zu wenig von dem, was AMD schon angedacht hat.
    "Bulldozer done better" wäre wohl die logisch bessere Formulierung.

    Laut den Folien bleibt Haswell jedoch weiterhin bei 'Intel Hyperthreading', was aber nicht heißt, dass CMT nicht doch irgendwann den Weg auf Intel-Silizium findet.

  24. Beitrag #23
    Grand Admiral
    Special
    Grand Admiral
    Avatar von Dresdenboy

    Registriert seit
    28.10.2003
    Ort
    Berlin
    Beiträge
    2.692
    Danke
    25
    Gedankt 68 Mal für 2 Themen
    Zitat Zitat von FredD Beitrag anzeigen
    Laut den Folien bleibt Haswell jedoch weiterhin bei 'Intel Hyperthreading', was aber nicht heißt, dass CMT nicht doch irgendwann den Weg auf Intel-Silizium findet.
    Das gute an so einem Marketingnamen ist, dass Intel schmerzfrei ein anderes Konzept dahinterlegen kann. Und wenn man sich eine dynamische Clusterzuteilung (nicht befehlsweise, aber z. B. für einen kleinen Befehlsstrang) vorstellt, kann man grob auch SMT darin erkennen, nur gälte "simultaneous" dann für die Befehlsstränge.
    Mein Bulldozer-Blog
    Twitter Feed @Dresdenboy.

    Ein bisschen Coding-Nostalgie: Erste Marching-Cubes-Implementation in einem 3k Intro

    Computing Nostalgia + History: C64, Am386DX40, Cx486, Amiga 1200, K6, K6-2, XP, A64, A64 X2, Athlon II X4

  25. Beitrag #24
    Themenstarter
    Admiral
    Special
    Admiral

    Registriert seit
    02.05.2009
    Beiträge
    1.642
    Danke
    76
    Gedankt 36 Mal für 6 Themen
    Neues GPU Design & 25% mehr EUs als Ivy Bridge

    http://vr-zone.com/articles/haswell-...#ixzz1iUkKTN8O

    Das wichtigste bleibt leider noch unbekannt (IPC Verbesserungen gegenüber Sandy Bridge)

  26. Beitrag #25
    Lieutenant
    Lieutenant
    Avatar von memory_stick

    Registriert seit
    04.08.2011
    Ort
    Schweiz
    Beiträge
    67
    Danke
    7
    Gedankt 0 Mal für 0 Themen
    soweit es denn verbesserungen werden...
    Soweit es nach den Gerüchten aussieht, soll Intel doch auf eine Art CMT-Design umsteigen, oder bin ich falsch informiert?
    Dies beduetet für mich, dass man (analog zu AMD mit BD) auch bei Intel nicht zwingend von einer "IPC" (welche IPC?) Verbesserung ausgehen kann... Eine Stagnation zu SB ist genauso zu erwarten.

    mfg memory_stick
    Wir sind ein gutes Team, so wie Starsky und Hutch, Turner und Hooch - Sie erinnern mich tatsächlich etwas an Hooch -

Seite 1 von 29 1234511 ... LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  
Single Sign On provided by vBSSO