ZFX
ZFX Neu
Home
Community
Neueste Posts
Chat
FAQ
IOTW
Tutorials
Bücher
zfxCON
ZFXCE
Mathlib
ASSIMP
NES
Wir über uns
Impressum
Regeln
Suchen
Mitgliederliste
Membername:
Passwort:
Besucher:
4397157
Jetzt (Chat):
18 (0)
Mitglieder:
5239
Themen:
24223
Nachrichten:
234554
Neuestes Mitglied:
-insane-

ZFX
Coding-Foren
Algorithmen und Datenstrukturen
Thread Sicherheit/Geschwindigkeit
Normal
AutorThema
FunMaker Offline
ZFX'ler


Registriert seit:
12.09.2005

Niedersachsen
Thread Sicherheit/GeschwindigkeitNach oben.
Ich habe lange im Internet gesucht aber keine befriedigende Antwort gefunden.

Mal abgesehen von Mutexen, Critical Sections und anderen Möglichkeiten Teile des Codes Thread sicher zu machen habe ich bisher meist einfach nen Bit gesetzt was einem Thread signalisiert hat das er etwas gerade nicht machen darf (und ihn in eine Schleife geschickt, verbraucht dann zwar leistung im Gegensatz dazu wenn man den Thread schlafen legt, aber nun gut).
Jetzt meine Frage: Ist das überhaupt sicher oder war es vielmehr Glück das ich keine Kollisionen gehabt habe?

Eine weitere Frage für mich ist - um sagen wir mal eine vernünftige Geschwindigkeit zu erreichen (>30 Frames bzw. Ticks pro Sekunde) - ist es ein Beinbruch Thread Objekte immer wieder aufs neue zu erstellen und die alten zu verwerfen(wenn sie ihre Arbeit für den Moment getan haben), ka wie aufwendig es für Windows ist Threads neu zu erstellen oder macht es schon Sinn wenn ein Thread erstellt wurde den bis zum Ende laufen zu lassen und die Dinge die der Thread machen soll anders zu kontrollieren(z.B. der Thread loopt, wird aber schlafen gelegt wenn er seine aktuelle Aufgabe erfüllt hat, bekommt er neue Informationen und wird wieder aktiviert.)

Mit Threads habe ich bisher nur in Delphi gearbeitet, würde aber gerne in C++ ebenfalls multithreaded arbeiten(wozu sonst nen i7 bestellt ) - welche Thread Implementierung ich verwenden würde weiß ich noch nicht aber da ich mit Boost bisher ganz gut Erfahrungen gemacht habe vermutlich Boost::Thread.
15.01.2009, 16:09:46 Uhr
Schrompf Offline
ZFX'ler


Registriert seit:
04.04.2006

Sachsen
Re: Thread Sicherheit/GeschwindigkeitNach oben.
Bits setzen ist evtl. ein dummer Gedanke... das ist keine atomare Operation, sondern ein Lesen, Ändern und Zurückschreiben. Google mal nach atomaren Operationen, da bieten die aktuellen Prozessoren bereits in Hardware ein paar nette Features.

Ansonsten sollte diese Art der Synchronisierung gehen. Solange das Gesamtsystem, dass Du damit synchronisierst, ansonsten funktioniert. Denn das ist das eigentliche Problem: Deadlocks zu vermeiden, alle konkurrierenden Zugriffe überhaupt zu identifizieren und am Ende ein System zu schreiben, dass eben möglichst wenig aufeinander angewiesen ist. Denn wenn Du einfach zwei Teile ihre Arbeit machen lässt und die aber beide permanent auf den selben Daten arbeiten, dann nützt Dir alle Absicherung nix - die beiden Threads verbringen den Großteil ihrer Zeit mit dem Warten auf den Partner und Dein Gewinn durch die Parallelisierung ist zum Fenster raus.

Für die Basisoperationen des Multithreadings schau ich mir gerade Intels Threading Building Blocks an. Boost::Threads sind ok, mit denen habe ich gute Erfahrungen gemacht. Allerdings sind die halt nur sehr grundlegend, komplexere Konstrukte wie JobQueues und sowas fehlen. Und atomare Operationen fehlen völlig. Die sind die eigentliche Magie für wirklich schnelle parallele Systeme. Ich habe mit Intels TBBs aber noch nicht genug Erfahrung, um schon eine Empfehlung dazu abgeben zu können.
15.01.2009, 17:12:57 Uhr
Dreamworlds Development
Helmut Offline
ZFX'ler


Registriert seit:
11.07.2002

Deutschland
280083044 helmut4242
Re: Thread Sicherheit/GeschwindigkeitNach oben.
Falls du MS VS 2005 oder höher benutzt und für das normale Windows programmierst, reicht es eine globale bool-Variable als volatile zu deklarieren. Die entsprechenden Instruktionen, die eine Neuanordnung der Instruktionen zur Laufzeit(!) verhindern, fügt der Compiler dann automatisch hinzu. Das ist dann so ziemlich die schnellste Synchronisierungsmethode, die es gibt (aber man muss aufpassen)

Schau dazu auch mal unter dem Schlüsselwort volatile in der MSDN.

Ciao
15.01.2009, 17:37:29 Uhr
Bomber-Revolution
Lord Delvin Offline
ZFX'ler


Registriert seit:
05.07.2003

Baden-Württemberg
166781460
Re: Thread Sicherheit/GeschwindigkeitNach oben.
Also boost::thread kann eigentlich alles, was du fürs erste brauchst und war für uns damals die beste und vor allem schnellste wahl.

Generell musst du dir halt überall überlegen, ob sich das parallelisieren lässt, ob das zu Problemen führen kann und wenn ja, ob man das Problem nicht vielleicht so umformulieren kann, dass man keine locks braucht um die Probleme zu umgehen oder auf Probleme zu beschränken, die nicht weiter schlimm sind.

Gerade wenn du auf Geschwindigkeit aus bist wirst du vermutlich nicht in der Lage sein viel zu Synchronisieren, weil sowas wie "atomare Operationen" auf großen mehrkernigen systemen eigentlich nicht vorhanden ist oder sau teuer. Du musst dir da also was besseres überlegen.

Wenn du uns verrätst was du parallelisieren willst, dann ham wir vielleicht auch Tipps, wie man das ohne oder mit sehr wenigen locks hinbekommt, aber grundsätzlich ist es immer ganz gut sachen zu parallelisieren, die sich garnicht in die quere kommen können.

Gruß
LordD
15.01.2009, 18:40:01 Uhr
Jörg Offline
ZFX'ler


Registriert seit:
03.12.2005

Nordrhein-Westfalen
133916438
Re: Thread Sicherheit/GeschwindigkeitNach oben.
Zitat von Helmut:
... reicht es eine globale bool-Variable als volatile zu deklarieren[...]Das ist dann so ziemlich die schnellste Synchronisierungsmethode, die es gibt (aber man muss aufpassen)


Ohne die entsprechende atomare Operation, mit der man mit dieser Variable umgehen kann, nuetzt das nichts und ist sehr gefaehrlich (ich verzichte hierbei auf Dekker und Peterson).
Wenn Du soetwas selber bauen willst, und dich auf die Win32-Umgebung beschraenkst, dann schau doch mal bei den InterlockedXXX-Funktionen nach. Damit kannst Du spin-locks ohne Syscalls bauen.
Allerdings ist das ein grosses Thema, ich empfehle da, noch ein paar 'Best Practices' von Intel und AMD zu lesen.

@LordDelvin
Welche Systeme meinst Du denn?

@Schrompf
TBB sind, wenn man denn mit ein paar 'Eigenheiten' leben kann, ziemlich performant, gehen allerdings weit ueber das genannte Szenario hinaus.

1 Mal gendert, zuletzt am 15.01.2009, 20:32:44 Uhr von Jörg.
15.01.2009, 20:27:54 Uhr
FunMaker Offline
ZFX'ler


Registriert seit:
12.09.2005

Niedersachsen
Re: Thread Sicherheit/GeschwindigkeitNach oben.
naja primär geht es dabei um Einheiten eines FPS

Meine Grundsätzliche Vorstellung wäre:

X Threads um durch die Einheitenliste zu gehen
- Wenn eine Einheit mit einer anderen interagiert können möglicherweise Konflikte auftreten. Während des Tickens der Einheiten werden die, wo bekannt ist, dass sie im View-Frustrum liegen in einen Puffer geschoben der von einem weiteren Thread ausgelesen wird (glaube die Boost Container sind Thread sicher und dafür verwendbar- müsste ich nochmal genau nachlesen) und dementsprechend dort gerendert(oder erst vorsortiert und später gerendert) wird.
Danach kommen dann KI Routinen und anderes Zeug was auch noch getan werden muss auch in mehreren Threads.

Klingt jetzt nach "mutest du dir da nicht zuviel zu" aber das ist auch keine Sache die ich innerhalb von 1/2 fertig bekommen möchte - sondern ich mache da ne Zeit lang intensiv was drann und nen paar Wochen später dann wieder - wanns fertig wird steht in den Sternen

In Delphi hatte ich das Projekt schon soweit das die Oberfläche fertig war und die Einheiten von der Steuerung fertig waren(sidn auch schon gut rumgefahren/rumgeflogen) - nur dann habe ich mir gedacht - scheiß auf Delphi - C++ muss her in Delphi hatte ich nur das Multithreading noch nicht von vornherein durchdacht - das möchte ich jetzt bereits in der Planung auf sicheren Füßen haben.

1 Mal gendert, zuletzt am 15.01.2009, 22:20:12 Uhr von FunMaker.
15.01.2009, 22:19:22 Uhr
Lord Delvin Offline
ZFX'ler


Registriert seit:
05.07.2003

Baden-Württemberg
166781460
Re: Thread Sicherheit/GeschwindigkeitNach oben.
[quote=Jörg]Welche Systeme meinst Du denn?[/quote]

Ganz normale amd64 mehrkernsysteme, wie sie heutzutage die meisten Leute kaufen. Bei 2 cpus muss ich zugeben, dass ich nicht weis, ob da sowas wie atomare operationen implementiert wurden, aber ich hoffe nicht, weil ich mir schon bei dem was z.z. angekündigt ist nicht mehr vorstellen kann, dass es da (systemweite!!) atomare Operationen geben kann.
Du musst dafür ja alle Prozessoren anhalten, auf einem Rechnen und dann alle weiterlaufen lassen und das ist bei zunehmender Zahl an "Prozessoren pro CPU" natürlich immer dämlicher.

Ich würd mir ganz ehrlich nicht gedanken über atomare operationen machen, auch wenn Leute sagen, sowas wäre gut oder es würde funktionieren.
Ihr werdet irgendwann feststellen, dass es DER Performancekiller sein wird.

Versucht euch lieber euer Problem so umzusortieren, dass es nicht kaputtgehen kann. Teilt es in echt disjunkte Teilprobleme auf, verschiebt die Startpunkte der einzelnen Threads...sowas.

@FunMaker: Öhm...also wenn du gute KI planst, dann kannst du eigentlich die KI in Threads auslagern und parallel berechnen, ohne dass sie sich gegenseitig schneiden, weil sie ja auf den Weltdaten nicht schreiben dürfen(oder zumindest sollten). Das sollte auch in absehbarer Zukunft deine CPU vollständig auslasten...aber vermutlich planst du ähnlich schwache KI wie man sie überall in spielen findet
Dann würd ich mal auf parallelisierbares update tippen...wenn deine Spielwelt nicht allzuviel Speicher braucht, dann kannst du sie vielleicht wie n DoubleBuffer immer in den andern Puffer kopieren und so einen nur lesen und den anderen nur schreiben. Dann solltest du auch ganz ohne locks auskommen können.

Keine Ahnung...mach dir halt gedanken was du genau erreichen willst, wie deine Spielwelt aussieht, was du von ihr Opfern willst, um gute parallelität zu erreichen und vor allem, ob es sich überhaupt lohnt. Denn viel zu oft sieht man leider, dass Leute gute Spielideeen in ein viel zu "schönes" Äußeres gießen wollen und dann nicht fertig werden...wenns nur ne Engine ist, dann probier mal das mit den "WorldBuffern" aus.
Gruß
15.01.2009, 23:49:01 Uhr
jumphigh Offline
ZFX'ler


Registriert seit:
30.06.2004

Thüringen
221436197 andreas_heyer@hotmail.com
Re: Thread Sicherheit/GeschwindigkeitNach oben.
Zitat von Lord Delvin:

Ganz normale amd64 mehrkernsysteme, wie sie heutzutage die meisten Leute kaufen. Bei 2 cpus muss ich zugeben, dass ich nicht weis, ob da sowas wie atomare operationen implementiert wurden, aber ich hoffe nicht, weil ich mir schon bei dem was z.z. angekündigt ist nicht mehr vorstellen kann, dass es da (systemweite!!) atomare Operationen geben kann.


Die gebräuchlichen SMP-Desktopsysteme haben einen *gemeinsamen* Speicher für alle Kerne und ein Speicherprotokoll, welches den Cache eines Kernes "aktualisiert", wenn man bei einem anderen Kern etwas ändert. Die atomaren Operationen funktionieren also, denn dort geht es ja nur um unteilbaren Speicherzugriff!

Zitat:

Du musst dafür ja alle Prozessoren anhalten, auf einem Rechnen und dann alle weiterlaufen lassen und das ist bei zunehmender Zahl an "Prozessoren pro CPU" natürlich immer dämlicher.


Was ist das denn für ein Quark??? Bei atomaren Operationen musste noch nie irgendwas angehalten werden! Könnte es sein, dass du nicht wirklich das Konzept von Parallelität verstanden hast?

Zitat:

Ich würd mir ganz ehrlich nicht gedanken über atomare operationen machen, auch wenn Leute sagen, sowas wäre gut oder es würde funktionieren.
Ihr werdet irgendwann feststellen, dass es DER Performancekiller sein wird.


Wie gut, dass keiner auf dich hört...

MfG
Andreas

PS: *SCNR* Aber das war zu drollig.
16.01.2009, 01:40:29 Uhr
www.high-and-heyer.de
Jörg Offline
ZFX'ler


Registriert seit:
03.12.2005

Nordrhein-Westfalen
133916438
Re: Thread Sicherheit/GeschwindigkeitNach oben.
Zitat von Lord Delvin:
Ganz normale amd64 mehrkernsysteme, wie sie heutzutage die meisten Leute kaufen. Bei 2 cpus muss ich zugeben, dass ich nicht weis, ob da sowas wie atomare operationen implementiert wurden, aber ich hoffe nicht, weil ich mir schon bei dem was z.z. angekündigt ist nicht mehr vorstellen kann, dass es da (systemweite!!) atomare Operationen geben kann.

Nein, da hast Du wohl mal etwas gelesen und in den falschen Hals bekommen. Die ersten 64bit Opterons hatten (warum auch immer) keine cmpxchg16-Instruktion mit in die Wiege bekommen, allerdings ist AMD dieser Mangel ziemlich schnell bewusst geworden und seit dem haben auch die AMD-Prozessoren die gleichen atomaren Instruktionen wie die Intels.

Zitat von Lord Delvin:

Du musst dafür ja alle Prozessoren anhalten, auf einem Rechnen und dann alle weiterlaufen lassen und das ist bei zunehmender Zahl an "Prozessoren pro CPU" natürlich immer dämlicher.

Man muss nicht alle Prozessoren anhalten, das waere wahrlich die "dämliche" Lösung. Moderne Prozessoren schauen naemlich vorher nach, bei wem ein potentieller Konflikt stattfindet, und nur im Fall des Falles wird der Zugriff auf die betroffene Cache-Line geregelt. (Das ist uebrigens der Grund, warum man bei bei Variablen Gedanken machen muss, wie ihr Alignment ist und welche Variablen eventuell noch in der selben Cacheline liegen, siehe auch "False Sharing").

Zitat von Lord Delvin:

Ich würd mir ganz ehrlich nicht gedanken über atomare operationen machen, auch wenn Leute sagen, sowas wäre gut oder es würde funktionieren.
Ihr werdet irgendwann feststellen, dass es DER Performancekiller sein wird.

Das ist Quatsch, denn wenn man synchronisieren muss, dann sind atomare Operationen um einiges schneller als Mutexe o.ae. Systemprimitiven.

Zitat von Lord Delvin:

Versucht euch lieber euer Problem so umzusortieren, dass es nicht kaputtgehen kann. Teilt es in echt disjunkte Teilprobleme auf, verschiebt die Startpunkte der einzelnen Threads...sowas.

Da hast Du insofern Recht, als man natuerlich alle unabhängigen Probleme auch unabhängig lassen sollte. Jegliche Art von Synchronisierung beeinträchtigt die Skalierbarkeit auf Mehrkernern, aber leider leider gibt es viele Algorithmen, die sich nicht so einfach "zerbrechen" lassen, und trotzdem möchte man diese gerne Multicore-fähig machen. Und genau bei diesen kommt es darauf an, die vorhandenen Abhängigkeiten der Teilprobleme möglichst effizient behandeln zu können.


Zitat von Lord Delvin:

[...]aber vermutlich planst du ähnlich schwache KI wie man sie überall in spielen findet
[...]

Na dass nenn ich ein komisches Argument...ich kann Dir zig primitiv-parallele Algorithmen aufzaehlen, die man auch nutzen kann, um Mehrkerner völlig auszulasten. Und? Wenn sie für das spezifische Projekt nicht gebraucht werden, dann muss ich sie auch nicht einbauen, ebenso wie eine "Ueber-KI", nur damit sie einen 8x-PC auslastet. Gerade die KI ist doch spielrelevant, wenn ich sicherstelle, dass sie einen 2-Kerner voll auslastet, was soll sie dann "mehr" auf einem 8-Kerner tun? Nein, hier kommt es auf Skalierbarkeit an, wenn eine einfache KI das Problem loest und auf einem groesserem System einfach schneller abgearbeitet wird, weil sie die parallelen Resourcen nutzen kann, dann ist das viel mehr wert!

PS:
Deine Worldbuffer-Idee kostet aber um einiges Speicher. Würdest Du eine Lösung, die bei N Prozessoren N-fachen Speicherbedarf hat, wirklich für gut befinden?

1 Mal gendert, zuletzt am 16.01.2009, 08:21:53 Uhr von Jörg.
16.01.2009, 08:19:21 Uhr
Lord Delvin Offline
ZFX'ler


Registriert seit:
05.07.2003

Baden-Württemberg
166781460
Re: Thread Sicherheit/GeschwindigkeitNach oben.
Jörg, du verstehst mich entweder falsch oder wir reden aneinander vorbei(ist auch garnicht bös gemeint, ich glaub nur einfach nicht, was du sagst):

Das mit den Atomaren Operationen hab ich aus ner Sysarch Vorlesung, die ich gerade höre, kann also nicht ganz so falsch sein. Und wenn AMD erst gedacht hat, dass man sowas nicht braucht hat das Gründe.

Das mit der Cache-Line hört sich nett an, zeigt aber einen denkfehler und hört sich so an, als hättest du meine Vorschläge nicht verstanden denn:
Natürlich kann man mit atomare Operationen auf Speicher ausführen, den man nur selbst hat, oder den nur wenige Leute haben, ABER wenn man der einzige ist, der die Cacheline im Cache hat, dann braucht man garnicht zu synchronisieren. Und wenn man nicht der einzige ist, dann muss man entweder die anderen anhalten oder ihnen die Cacheline wegnehmen oder sonst was komisches machen. Weil du halt nicht in einem Prozessortakt testen kannst, ob alle anderen Prozessoren mit deinem Speicherbereich jetzt das machen wollen was du machen willst und du dann halt größere Probleme bekommst. Kann aber durchaus sein, dass man das für kleine Prozessorzahlen noch nicht merkt.
So hab ich Threads aber zugegebener Maßen nie eingesetzt...mein Ziel war immer, dass es fast beliebig skaliert.

Wenn du mir das mit den Atomaren Operationen nicht glaubst, dann mal dir mal auf nem Papier auf, wie du atomar mit 100+ Prozessoren aus einer Queue Sachen entnehmen willst.

Ich mein kann sein das ich mich irre, aber mir ist momentan wirklich vollkommen unklar, wie das funktionieren soll, also wenn dir n Weg einfällt oder du schon einen kennst her damit


Und das mit dem Worldbuffer hast du leider garnicht verstanden, der verdoppelt die größe der Welt bei naiver implementierung genau. Egal wieviele Threads man laufen lässt oder wieviele man bearbeiten kann.
Die Idee ist einfach, von einem Buffer nurnoch zu lesen und in den andern nurnoch zu schreiben. Funktioniert natürlich nur, wenn man die Welt so formulieren kann, dass in einem "Feld" nur einer schreibt...aber man kann vielleicht auch einfach Gebiete an Threads vergeben...da müsste man dan wirklich das Spiel bzw. seine mechanik kennen.


Vielleicht betrachte ich das Problem auch einfach in viel größerer Allgemeinheit als ihr...keine Ahnung.

Gruß
Lord D
16.01.2009, 09:54:20 Uhr
Jörg Offline
ZFX'ler


Registriert seit:
03.12.2005

Nordrhein-Westfalen
133916438
Re: Thread Sicherheit/GeschwindigkeitNach oben.
@FunMaker: Ja freilich ist es besser, Threads schlafen zu legen statt sie zu zerstoeren und neu zu erstellen.

Zitat von Lord Delvin:
Das mit den Atomaren Operationen hab ich aus ner Sysarch Vorlesung, die ich gerade höre, kann also nicht ganz so falsch sein.

Deine Vorlesung kenne ich nicht, wohl aber die technischen Dokumente von Intel und AMD (die uebrigens frei verfuegbar sind). Da solltest Du noch einmal nachfragen, welches grosse System da nichts anbietet und vor allem was die Implikationen sind.
Vieles kann man ohne atomare Operationen per Software nachbilden, aber nicht alles is so einfach.
Folgende Architekturen kann man in SMP-System verbauen und alle bieten atomare Instruktionen:
x86 (Intel, AMD), x86-64, PPC, CELL (da haben die Designer extra drauf geachtet, man haette das SPE-Orchester auch rein message-passing-basiert machen koennen), LRB, ARM, Itanium, Motorola, Sun.
Sogar unter CUDA kannst Du die auf NVidia-HW nutzen, wenn du sie brauchst. Sogar Netwerkarchitekturen bieten das (Infiniband afaik, muesste aber nochmal nachschauen).
Klar gibt es auch Architekturen, die keine atomaren Operationen anbieten, aber sie sind die Hoelle und werden i.A. nicht fuer general-purpose Code eingesetzt, sondern dort laufen dann nur passende Algorithmen.

Zitat von Lord Delvin:

Das mit der Cache-Line hört sich nett an...

Es ist momentan der gaengige Weg. Es ist klar, dass eine solche zentrale Verwaltung entweder immer komplexer wird (Chipgroesse und Energieaufwand) oder hierarchisch aufgebrochen wird, was zu ungunsten der Performance geht. Ich kenne Designer die sagen, mehr als 4 Cores bekommen wir nicht mehr energieeffizient auf einen Die, entweder opfern wir Performance oder verbrauchen mehr.

Du scheinst etwas in mein Posting zu interpretieren, was ich nie gesagt habe. Jegliche Art von Synchronisierung kostet, am besten ist man dran, wenn man es gar nicht braucht. Das steht wohl ausser Frage.
Leider gibt es aber nicht viele Dinge, die sich komplett ohne Synchronisierung erledigen lassen. Und wenn man synchronisieren muss, sollte man das nutzen, was die Hardware bietet. Andernfalls macht man naemlich nichts weiter, als so etwas in Software nachzubauen. Wenn Du vom Algorithmus einen gemeinsam genutzten Counter brauchst, kannst Du entweder atomare Operationen nutzen oder selber alles mit (Spinlocks?) nachbauen. Was wird wohl schneller sein? (Das ein solcher Counter ein Bottleneck werden kann, ist klar).

Es gibt gute Gruende, warum sich die aktuelle Situation darstellt als Cache-koherente SMP Architektur mit atomaren Operationen. Einer duerfte wohl sein, dass alternative Architekturen momentan entweder zu teuer, zu aufwaendig oder nicht performant genug sind. Und solange man seine Software auf den Mainstream-Architekturen laufen lassen will/muss, lohnt es nicht, Empfehlungen zu geben, welche sie auf Uni/Labor/Spezial-Hardware beziehen.
16.01.2009, 10:39:27 Uhr
rave3d Offline
ZFX'ler


Registriert seit:
29.10.2005

Bayern
279915923 matthias.gubisch@gmx.de
Re: Thread Sicherheit/GeschwindigkeitNach oben.
Atomare Operationen sind momentan noch schneller als irgendwelche anderen Sychornisationsmethoden, die ja auch nicht wirklich ohne Atomare Operationen auskommen (Stichwort TestAndSet mal als Beispiel)

Bei der momentanen Anzahl an Kernen in einer CPU, denke ich sind Atomare Operationen performancetechnisch sicher kein Problem.

Wenn die Kernzahl weiter steigt, wird man IMHO nicht mehr mit den aktuellen Caching-Techniken auskommen sondern sich da neue Ansätze überlegen müssen. Weil Atomare Operationen auf Cache-Daten ausführen ist ein Problem, ein anderes ist den Cache für viele viele Kerne (100+) konsitent zu halten.

Ich vermute dass wir in diesem Bereich mit steigende Kernzahl sicherlich einige Neuerungen erleben werden.
16.01.2009, 10:43:38 Uhr
Normal


ZFX Community Software, Version 0.9.1
Copyright 2002-2003 by Steffen Engel