Seite 2 von 2 ErsteErste 12
Ergebnis 26 bis 39 von 39
  1. Beitrag #26
    Themenstarter
    Redaktion
    Redaktion
    Avatar von Opteron
    Registriert seit
    13.08.2002
    Beiträge
    21.562
    Danke Danke gesagt 
    348
    Danke Danke erhalten 
    2.122
    Zitat Zitat von Gipsel Beitrag anzeigen
    Da ist auch ein Fehler im Bobcat-Pipelinediagramm. Das ist ja gewissermaßen ein Ablaufplan, der immer strikt von links nach rechts abläuft und eben Verzweigungen entsprechend der Pfeile enthalten kann. Das Problem ist jetzt, daß der Pfeil nach RegRead zu AGU offensichtlich in die falsche Richtung zeigt (weg von AGU, aber dann würde man da ja nie hinkommen ;)). Denn das läuft doch so ab:
    Ein AGU-Befehl wir gescheduled, die Adresse(n)/Offset/Scale wird aus den Registern gelesen (RegRead), der AGU-µOp macht eine Adresse draus (AGU), woraufhin auf den DatenCache zugegriffen wird (DC1+2). Tritt dabei ein L1-Miss auf, geht es nach DC2 mit dem L2-Zugriff weiter, der dann irgendwann auch das Ergebnis liefert. In jedem Fall kehrt man irgendwann auf die "Hauptlinie" des Diagramms zurück und schreibt die Daten in ein Register (Writeback).
    Ok, sagen wir mal der Pfeil ist falsch rum. Dann bemäkel ich mal Deine Idee des RegRead. Da steht sicher nichts Relavantes für die AGU drin. Aber den REgread braucht man trotzdem, da wenigstens 1 Parameter einer Instruktion ja ein Register sein sollte ;)


    Wie gesagt ist das ein Ablaufdiagramm, kein Datenflußdiagramm. Result-Forwarding (für ALUs wichtiger) gibt es natürlich trotzdem, so daß eine abhängige ALU-Instruktion, die auf eine AGU-Instruktion gewartet hat, direkt loslegen kann, wenn die AGU-Instruktion bei Writeback ankommt. Sowas hat der Scheduler im Griff. Deswegen steht ja auch "Load-Use-Latency L1 Hit: 3-cyles" dran, sonst wären es 5 (3 für die AGU-Instruktion und Zugriff + Writeback der AGU + ReadReg der ALU).
    Naja ein Pfeil von DC1 zur ALU wäre schon recht nett, fände ich, aber gut. Wenns nur ein Ablaufdiagramm für entweder ALU oder AGU Ops ist ... ok.

    Was uns zeigt, das µcoded Instruktionen 2 Zyklen Penalty haben. Die Fast-Decoder erzeugen einen Offset in den µCode-ROM, der Zugriff dauert 2 Takte, dann geht es weiter wie normal.
    Ja. Keine Einsprüche ^^

    Zitat von Opteron
    Für die AGU hieße das, dass die AGU ne Adresse vor die ALU liefert und dann die Berechnung losgeht.
    Siehe oben. Eine ALU kann mit einer Adresse gar nichts anfangen, die rechnet immer nur mit Werten in Registern. Die AGU liefert die Daten im Registerfile ab, danach kann die ALU mit den Daten rechnen.
    a) Ja, eine ALU braucht keine Adresse ^^
    b) Einspruch: Eine CISC ALU kann auch direkt mit Werten aus dem Speicher rechnen. Nur RISC Maschinen ALUs haben die Einschränkung nur mit Registerdaten arbeiten zu können.
    c) Die AGU liefert nichts ins Registerfile ab ;-) Die AGU generiert nur ne Adresse, die dann direkt der L/S Unit übergeben wird.

    Zitat von Opteron
    Problem bei Deiner Idee, dass das eingeschoben wird und die ALU Stufe damit ersetzt wird: Wo ist die ALU ? Wird dann nichts berechnet ?
    Nö, eine AGU-Instruktion ist eine AGU-Instruktion. Eine abhängige (oder auch unabhängige) ALU-Instruktion läuft getrennt durch die Pipeline.
    Ja - und nein .. zumindest bei K8/10 gabs ja die MacroOps. Da läuft je eine ALU und AGU in Form einer MacroOp zusammen durch die Pipeline. Erst der Scheduler splittet das dann auf. Deswegen verwirrt mich das etwas, ich geh da von einer vollen MacroOp aus, und will da deren Weg nachvollziehen können. So hat man ja "nur" ein Pipeline Diagramm entweder für ALU oder AGU Opteration - langweilig ^^

    Nö, das sind praktisch zwei parallele Pipes. Die waren bloß zu faul eine Verzweigung (oder eben 2 Pipelinediagramme) wie bei Bobcat zu zeichnen (wo sie ja auch glatt den Pfeil falsch rum erwischt haben). Wie oben schon gesagt, beträgt die Branch Mispredict Penalty eines K10 nur 10 Takte, die beiden DC-Stufen treffen also wie bei Bobcat nur für AGU-Instruktionen zu.
    Ok würde dann auch Sinn machen und ich frag mich dann langsam, ob man das ganze nicht einfacher machen könnte ^^

    Wieso muss das alles in 1 Diagramm gepfercht werden ... wie wärs mit übersichtlichen Einzeldiagrammen ^^

    Der wird vielleicht immer gleich eine ganze Cacheline (64Byte) über 2 Takte fetchen (oder die 256 Bit kommen dadurch zustande, daß über 2 Takte je 128Bit geholt werden) und erst damit weitermachen, wenn der entsprechende Puffer hinreichend leer ist. Wenn ich mich richtig erinnere hatte K8 einen 128Bit fetch in einen 24 Byte Puffer. Die nächsten 16 Byte konnten erst gefetcht werden, wenn im Puffer 8 Byte oder weniger übrig waren. Und dann kann es schon zu einem temporären Engpaß kommen. Aber wie gesagt, nagle mich nicht darauf fest.
    Hm, ok ne ganze Cacheline in 2 Takten .. klingt logisch, ist mal mein Favorit ;-)

    Danke & ciao werd mal noch ne Nacht drüber schlafen und morgen versuchen das Pipelinefiasko zu beheben. Wahrscheinlich werd ich meine eigenen Diagramme Zeichnen müssen (falls jemand Softwaretipps für sowas hat (Visio ?), bitte gerne).

    Alex

  2. Beitrag #27
    Grand Admiral
    Special
    Grand Admiral
    Avatar von Dresdenboy

    Registriert seit
    28.10.2003
    Ort
    Berlin
    Beiträge
    3.023
    Danke Danke gesagt 
    28
    Danke Danke erhalten 
    121
    Ich bin wieder da und habe mich so langsam wieder eingefunden ;) Es gab ja auch soviel Neues letzte Woche.

    Powerpoint ist für Pipelinezeichnen wahrscheinlich ausreichend solange sie nicht so überfrachtet wird. Der Pfeil bei der AGU-Stufe ist ja tatsächlich falsch und soll wohl andersherum stehen. Das ginge per Photoshop. Ist ja derzeit in Mode ;)

    Waren die zusätzlichen Fetch-Stufen nicht im Zusammenhang mit Prefetch genannt? Bei einer falschen Vorhersage kämen weitere Fetch-Zyklen hinzu. Außerdem wurden irgendwo auch das maximale Decoding von 22 Bytes pro Takt genannt.

    Sonst hier auch noch meine kleinen Anmerkungen:
    - Pentium 1 ist In-Order superskalar, PPro hatte erst OoOE.
    - Virtualisierung u. 64bit eröffnen dem Bobcat auch weitere Einsatzgebiete als einem Atom.
    - die kleine FPU ist natürlich praktisch und hier wurde im Paper zwar nur der Multiplier beschrieben, welcher aber oft auch die meiste Fläche beansprucht:


    Edit: Ich habe die Pipeline mal fix in MSPaint editiert (mehr habe ich hier nicht):
    http://info.nuje.de/bobcat_pipeline_new.jpg
    oder
    http://info.nuje.de/bobcat_pipeline_new.png

    Achso, der Zoo-Bobcat ist hier ;) :
    http://info.nuje.de/Bobcat_pic.jpg
    Geändert von Dresdenboy (06.09.2010 um 13:26 Uhr)

  3. Beitrag #28
    Admiral
    Special
    Admiral
    Avatar von Gipsel
    Registriert seit
    10.10.2002
    Ort
    Hamburg
    Beiträge
    1.289
    Danke Danke gesagt 
    1
    Danke Danke erhalten 
    81
    Zitat Zitat von Opteron Beitrag anzeigen
    Ok, sagen wir mal der Pfeil ist falsch rum. Dann bemäkel ich mal Deine Idee des RegRead. Da steht sicher nichts Relavantes für die AGU drin. Aber den REgread braucht man trotzdem, da wenigstens 1 Parameter einer Instruktion ja ein Register sein sollte ;)
    ??
    Na sicher benötigt eine AGU Register! Stelle Dir mal vor, Du willst auf die Speicherstelle [rax+rbx*8+8] zugreifen, dann muß die AGU wohl die Werte der Register rax und rbx lesen. Wenn Du was schreiben willst, muß auch der Wert, der geschrieben werden soll, aus dem Regfile gelesen werden.
    Zitat Zitat von Opteron Beitrag anzeigen
    b) Einspruch: Eine CISC ALU kann auch direkt mit Werten aus dem Speicher rechnen. Nur RISC Maschinen ALUs haben die Einschränkung nur mit Registerdaten arbeiten zu können.
    Nur werden eben seit K5 bzw. Pentium Pro keine CISC-ALUs mehr verbaut. Deswegen benötigt man ja den ganzen x86->µOps-Decoding-Kladderadatsch, damit man dahinter einen schönen RISC-Kern packen kann ;)
    Zitat Zitat von Opteron Beitrag anzeigen
    c) Die AGU liefert nichts ins Registerfile ab ;-) Die AGU generiert nur ne Adresse, die dann direkt der L/S Unit übergeben wird.
    Die dann den Zugriff macht (das sind die DC-Stufen, DC steht für Data Cache) und den gelesenen Wert wird dann in der Writeback-Stufe ins Registerfile geschrieben (wenn was in den Speicher geschrieben wird, natürlich nicht). Wie sonst sollen 3 Zyklen load-to-use Latency hinkommen? Im Falle eines Cache-Misses, verzweigt die Pipeline ja nicht umsonst zum L2-Zugriff.
    Zitat Zitat von Opteron Beitrag anzeigen
    Ja - und nein .. zumindest bei K8/10 gabs ja die MacroOps. Da läuft je eine ALU und AGU in Form einer MacroOp zusammen durch die Pipeline. Erst der Scheduler splittet das dann auf. Deswegen verwirrt mich das etwas, ich geh da von einer vollen MacroOp aus, und will da deren Weg nachvollziehen können. So hat man ja "nur" ein Pipeline Diagramm entweder für ALU oder AGU Opteration - langweilig ^^
    Aber so ist es nunmal. Auch im K8/K10 haben die ALU-µOp- und AGU-µOp-Bestandteile nach ihrer Trennung unterschiedliche Wege genommen.
    Zitat Zitat von Opteron Beitrag anzeigen
    Ok würde dann auch Sinn machen und ich frag mich dann langsam, ob man das ganze nicht einfacher machen könnte ^^

    Wieso muss das alles in 1 Diagramm gepfercht werden ... wie wärs mit übersichtlichen Einzeldiagrammen ^^
    Dann hast Du insgesamt 3 oder noch mehr Diagramme mit lauter unterschiedlichen Latenzen. Wir auch irgendwie unübersichtlich.

  4. Beitrag #29
    Themenstarter
    Redaktion
    Redaktion
    Avatar von Opteron
    Registriert seit
    13.08.2002
    Beiträge
    21.562
    Danke Danke gesagt 
    348
    Danke Danke erhalten 
    2.122
    @Dresdenboy:
    Ok, Danke, dass Du es Dir angeschaut hast. Also dann ganz sicher der Pfeil falsch herum.

    Da nehm ich dann mal als Ersatz gleich Dein photoshop äh - paint Bild, haha :)

    Dann mal zum Text, bzw. die Eckdaten:
    a) In was gibt man jetzt die Branch misprediction an ? Das ist doch immer der best case, oder ?
    Also im Vergleich zw. K8 & Bobcat dann der Fall ohne AGU, das wären dann die
    10 <> 13 Takte, richtig ?

    Also haben wir 3 Stufen mehr, das sind
    a) RegRead
    b) Decode 3 (bzw. Decode 2, je nach Zählweise)
    c) WriteBack

    Die BobC Zusatzstufe Decode 2 (oder 1) überlappt sich mit der Pick Unit des K8, und "zählt" somit nicht.

    Stimmen die Fakten jetzt ? Dann bitte kurzes "Go" von Dir und/oder Gipsel, dann mach ich mich mals ans Umschreiben.

    @Gipsel:
    Hab in Agners OptimierungsPDF noch das hier gefunden:
    Misprediction penalty
    AMD manuals say that the branch misprediction penalty is 10 clock cycles if the code
    segment base is zero and 12 clocks if the code segment base is nonzero. In my
    measurements, I have found a minimum branch misprediction penalty of 12 and 13 clock
    cycles, respectively. The code segment base is zero in most 32-bit operating systems and
    all 64-bit systems. It is almost always nonzero in 16-bit systems (see page 129).
    The exact length of the pipelines is not known but it can be inferred that it has approximately
    twelve stages, based on the fact that the branch misprediction penalty is measured to 12
    clock cycles.
    Also nehmen wir mal die idealen 10 Takte, oder ? Das sollte dann ja passen, Die 13 Takte bei Bobcat sind sicherlich auch best case.



    - Pentium 1 ist In-Order superskalar, PPro hatte erst OoOE.
    Das mit dem P1 ist klar, ich wollte da eigentlich "nach dem P1" schreiben (und dachte, dass ich das auch gemacht hätte), aber irgendwie ist wohl einer unüberlegten Umformulierung zum Opfern gefallen ^^ Danke fürs Aufpassen.

    Edit:
    @Gipsel:
    Hat sich überlappt, Antwort folgt, aber das passt schon so denke ich mal, gibts nicht viel dagegen zu sagen ;-)

    ciao

    Alex
    Geändert von Opteron (06.09.2010 um 15:32 Uhr)

  5. Beitrag #30
    Grand Admiral
    Special
    Grand Admiral
    Avatar von Dresdenboy

    Registriert seit
    28.10.2003
    Ort
    Berlin
    Beiträge
    3.023
    Danke Danke gesagt 
    28
    Danke Danke erhalten 
    121
    Bzgl. Agners Kommentar: Da habe ich auch keine Erklärung parat, warum die 10 Zyklen da nicht erreicht werden. Die von dir aufgezählten Stufen wären zumindest der sichtbare Unterschied.

    Anandtech hat den Pfeil gleich weggelassen:


    Spannender ist natürlich, wie oft die Penalty zuschlägt. Beim Bobcat eher seltener als bei den Hounds (Canines, der Ersatz für K9?).

    Die Fetch-Stufen, welche später an den Anfang springen, sind nach meinem Verständnis die Fälle, wo genauere Sprungvorhersagen den Pfad doch noch anders vorhersagen. Das Prinzip finde ich elegant und habe es unter "Late Cancelling" im Kopf gespeichert. So etwas setze ich bei Bedarf auch in zeitkritischen Software-Geschichten ein, wenn jede ms zählt, aber zu früherer Zeit noch keine so hohe Sicherheit über das Ergebnis besteht. Da die der Vorhersage folgenden Aktionen (beim Bobcat das Decoding) abbrechbar sind, hat man auf jeden Fall den Zeitgewinn und bei falscher Vorhersage einen kleinen Verlust (Zeit, Energie) anstatt mit der falschen Vorhersage bis zu den EX-Stufen durchzulaufen.

  6. Beitrag #31
    Redaktion
    Redaktion
    Avatar von Dr@
    • Mein System
      Notebook
      Modell: FSC Lifebook S2110, HP Pavilion dm3-1010eg
      Prozessor: Turion 64 MT37, Neo X2 L335, E-350
      Mainboard: E35M1-I DELUXE
      Arbeitsspeicher: 2x1 GiB DDR-333, 2x2 GiB DDR2-800, 2x2 GiB DDR3-1333
      Grafikkarte: RADEON XPRESS 200m, HD 3200, HD 4330, HD 6310
      Display: 13,3", 13,3" , Dell UltraSharp U2311H
      Festplatte(n): 100 GB, 320 GB, 120 GB +500 GB
      Optische Laufwerke: DVD-Brenner
      Betriebssystem(e): WinXP SP3, Vista SP2, Win7 SP1 64-bit
      Browser: Firefox 13
    • Mein DC

      Dr@ beim Distributed Computing

      Aktuelle Projekte: Collatz Conjecture
      Rechner: Zacate E-350 APU
      Mitglied der Kavallerie: Nein
      BOINC-Statistiken:

    Registriert seit
    19.05.2009
    Ort
    Baden-Württemberg
    Beiträge
    12.320
    Danke Danke gesagt 
    353
    Danke Danke erhalten 
    4.515
    Blog-Einträge
    1
    Hallo,

    Der Artikel ist zwar in der jetzigen Form rund, allerdings gibt es ja einige Neuigkeiten.

    Hat da jemand Lust die Hier noch mit einzuarbeiten?

    Ich hätte das gesamte neue Bildmaterial und könnte es hier entsprechend hochladen.


    Ich wollte jetzt allerdings nicht einfach am Text groß umbauen, bevor wir das weitere Vorgehen mal besprochen haben. Zudem ist meine Zeit begrenzt. Es wäre aber schön, wenn man hier zentral auch die aktuellsten Infos zum Ontario finden könnte.

  7. Beitrag #32
    Themenstarter
    Redaktion
    Redaktion
    Avatar von Opteron
    Registriert seit
    13.08.2002
    Beiträge
    21.562
    Danke Danke gesagt 
    348
    Danke Danke erhalten 
    2.122
    Zitat Zitat von Dr@ Beitrag anzeigen
    Hallo,

    Der Artikel ist zwar in der jetzigen Form rund, allerdings gibt es ja einige Neuigkeiten.
    Naja, rund ist was anderes, da sind noch einige Fehler drin ^^

    Ich wollte jetzt allerdings nicht einfach am Text groß umbauen, bevor wir das weitere Vorgehen mal besprochen haben. Zudem ist meine Zeit begrenzt. Es wäre aber schön, wenn man hier zentral auch die aktuellsten Infos zum Ontario finden könnte.
    Naja, das Neue ist doch praktisch alles harte Daten, keine Spekulation mehr.
    Da würde sich anbieten nen Unterpunkt "gesichterte Daten" sowie "Modellpolitik" einzupflegen.
    Der Artikel, so wie er jetzt ist, befasst sich ja mit den technischen Innereien, das was jetzt noch dazukommt ist (abgesehen von den Korrekturen) nur noch Marketing und Praxistests / Benchmarks.

    Würde vorschlagen die Punkte das einfach zu ergänzen, was meinst Du ?

    Eventuell würde sich auch schon ein neuer Sammelthread rentieren. Der aktuelle ist ja explizit nur für Bobcat, das sind nur die x86 Kerne. Wenn Du jetzt Ontario/Zacate Material ergänzen willst, wär das eigentlich hier fehl am Platz.

    ciao

    Alex

  8. Beitrag #33
    Grand Admiral
    Special
    Grand Admiral

    Registriert seit
    18.01.2007
    Beiträge
    4.418
    Danke Danke gesagt 
    1.269
    Danke Danke erhalten 
    74
    Ich denke der Artikel ist abgeschlossen.

    Was kommt, das sind dann konkrete Daten und Produkte - was einen vollständigen neuen eigenen Artikel wert ist. Man muss auch mal einen Punkt setzen können.

    Gruß Bobo(2010)

  9. Beitrag #34
    Themenstarter
    Redaktion
    Redaktion
    Avatar von Opteron
    Registriert seit
    13.08.2002
    Beiträge
    21.562
    Danke Danke gesagt 
    348
    Danke Danke erhalten 
    2.122
    Noch ne kleine Zusatzinfo, aus nem IEEE Bobcat Paper:
    Bobcat includes a small yet efficient OoO
    load/store unit (LSU). Capable of tracking
    up to 26 in-flight loads and 22 stores, this
    processor is AMD’s first fully OoO LSU. It
    supports both loads bypassing older loads
    and loads bypassing older nonconflicting
    stores
    . The Bobcat LSU can perform an
    8-byte load and an 8-byte store on every
    cycle, and it supports a three-cycle load-to-
    use pipeline. The data cache supports up to
    eight outstanding cache misses, as well as
    hits beneath misses. Critical-word forward-
    ing is used on cache misses to reduce effective
    cache miss latency.
    Hübsch, also "memory disambiguation" bei Bobcat. Sicherlich mit ein Grund, wieso der kleine Kern relativ gut mithalten kann.

  10. Beitrag #35
    Grand Admiral
    Special
    Grand Admiral
    Avatar von Markus Everson

    Registriert seit
    22.10.2004
    Ort
    Deutschland
    Beiträge
    5.754
    Danke Danke gesagt 
    134
    Danke Danke erhalten 
    162
    Blog-Einträge
    1
    Ich hab keinen besseren Platz gefunden um die Frage zu stellen - also bitte nicht gleich schlagen.

    Ist HSA nur wieder eine weitere Eintagsfliege im Bullshit-Bingo oder verbirgt sich dahinter ein Blick auf AMDs künftige Ausrichtung?
    (-> subBobcat)

  11. Beitrag #36
    Redaktion
    Redaktion
    Avatar von Dr@
    • Mein System
      Notebook
      Modell: FSC Lifebook S2110, HP Pavilion dm3-1010eg
      Prozessor: Turion 64 MT37, Neo X2 L335, E-350
      Mainboard: E35M1-I DELUXE
      Arbeitsspeicher: 2x1 GiB DDR-333, 2x2 GiB DDR2-800, 2x2 GiB DDR3-1333
      Grafikkarte: RADEON XPRESS 200m, HD 3200, HD 4330, HD 6310
      Display: 13,3", 13,3" , Dell UltraSharp U2311H
      Festplatte(n): 100 GB, 320 GB, 120 GB +500 GB
      Optische Laufwerke: DVD-Brenner
      Betriebssystem(e): WinXP SP3, Vista SP2, Win7 SP1 64-bit
      Browser: Firefox 13
    • Mein DC

      Dr@ beim Distributed Computing

      Aktuelle Projekte: Collatz Conjecture
      Rechner: Zacate E-350 APU
      Mitglied der Kavallerie: Nein
      BOINC-Statistiken:

    Registriert seit
    19.05.2009
    Ort
    Baden-Württemberg
    Beiträge
    12.320
    Danke Danke gesagt 
    353
    Danke Danke erhalten 
    4.515
    Blog-Einträge
    1
    FSA ==> HSA

    AMD Fusion System Architecture is now Heterogeneous Systems Architecture

    Außer dem Namen hat sich nichts verändert.

  12. Beitrag #37
    Grand Admiral
    Special
    Grand Admiral

    Registriert seit
    18.01.2007
    Beiträge
    4.418
    Danke Danke gesagt 
    1.269
    Danke Danke erhalten 
    74

    Raider ist Twix geworden - warum Fusion heterogeneous wird

    Zitat Zitat von Dr@ Beitrag anzeigen
    FSA ==> HSA

    AMD Fusion System Architecture is now Heterogeneous Systems Architecture

    Außer dem Namen hat sich nichts verändert.
    Tja - obs an Arctic Cooling liegt ...

    MFG Bobo(2012)
    Geändert von Bobo_Oberon (01.02.2012 um 17:05 Uhr)

  13. Beitrag #38
    Grand Admiral
    Special
    Grand Admiral
    Avatar von WindHund
    • Mein System
      Desktopsystem
      Prozessor: AMD FX-8350 Eight-core @ Asus enhancement Mode
      Mainboard: ASUS Sabertooth 990FX/Gen3 R2.0 sponsored by P3D
      Kühlung: WaKü EK WB Supreme LTX 366x40mm Radiator 6l Brutto m³
      Arbeitsspeicher: 4x 8GiB Crucial DDR3-1866 CL11 ECC DR
      Grafikkarte: 2x XFX Radeon R7970 DD 6GiB @ CrossFireX
      Display: 37" LE37A550P1R 60Hz 550cd/m Full HD -> best part of my system
      SSD(s): Samsung 830 128GB, Crucial BX100 256GB native SATA3
      Festplatte(n): 1x SATA2 Samsung HD103UJ, 1x SATA3 WD75000AAKS, 1x USB3.0 boost M.2 128GB
      Optische Laufwerke: 1x HL-DT-ST BD-RE BH10LS30 SATA2
      Soundkarte: ALC892 HD Audio (onboard)
      Gehäuse: SF-2000 Big Tower
      Netzteil: Corsair HX850W (80+ Silber)
      Betriebssystem(e): Windows 10 x64 Professional (up to date!)
      Browser: @Chrome.Google.CPU_Last_niedrig
      Sonstiges: Gehäuselüfter: 4x200mm + 7x120mm (inklusive Radiatorlüfter extern)
    • Mein DC

      WindHund beim Distributed Computing

      Aktuelle Projekte: SIMAP, Einstein, Collatz, RadioAktiv
      Lieblingsprojekt: none, try all
      Rechner: FX-8350, FX-6300, Galaxy S2 2xR7970 + 1xGTX580 + Galaxy SII
      Mitglied der Kavallerie: Nein
      BOINC-Statistiken:
      Folding@Home-Statistiken:

    Registriert seit
    30.01.2008
    Ort
    Im wilden Süden (0711)
    Beiträge
    8.936
    Danke Danke gesagt 
    1.151
    Danke Danke erhalten 
    70
    @Bobo
    Wenn dem so ist, warum schreiben sie dann: AMD Fusion12 Developer Summit in June 2012
    Ich glaube eher, das liegt an der Standardisierung von HSA.

  14. Beitrag #39
    Grand Admiral
    Special
    Grand Admiral

    Registriert seit
    18.01.2007
    Beiträge
    4.418
    Danke Danke gesagt 
    1.269
    Danke Danke erhalten 
    74

    Grins

    Zitat Zitat von WindHund Beitrag anzeigen
    @Bobo
    Wenn dem so ist, warum schreiben sie dann: AMD Fusion12 Developer Summit in June 2012
    Ich glaube eher, das liegt an der Standardisierung von HSA.
    Du kennst doch die überlasteten Praktikanten von AMDs PR-Abteilung ... und da dort personell gestrichen wurde - glaube ich erst an den Namen, wenns zu diesem Datum auch so läuft

Seite 2 von 2 ErsteErste 12

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •