Die PC Games Hardware hat sich mit der CPU-Performance unter StarCraft II beschäftigt. Die erste Erkenntnis dabei ist, daß das Spiel nichts mit mehr als zwei Rechenkernen anfangen kann, dafür aber anscheinend große Caches und generell Intel-Prozessoren mag. Die zweite Erkenntnis ist, daß das Spiel offenbar problemlos auch in Richtung totale CPU-Limitierung zu treiben ist, wenn man nur die richtige Szene auswählt – bislang ist StarCraft II ja in erster Linie als Grafikkarten-Benchmark bekannt. Mit der von der PCGH angesetzten Benchmark-Szene ist das Spiel jedoch selbst bis hinauf auf 1920x1080 mit 4x Anti-Aliasing noch einwandfrei CPU-limitiert – sehr gut daran zu sehen, daß zwischen Phenom II X6 1090T mit 3.2 GHz und Phenom II X6 1055T mit 2.8 GHz bei einem Taktunterschied von 14,3 Prozent eine Mehrperformance von (über)perfekt skalierenden 14,7 Prozent liegt.

Und um eine Empfehlung für eine CPU abzugeben, welche selbst unter der extrem schlauchenden Szene der PCGH noch auf durchschnittlich 24 fps oder mehr kommt: Da passen dann nur noch Phenom-Prozessoren mit 3.2 GHz Takt und mehr (Bedingung: 6 MB Level3-Cache), Core 2 Prozessoren mit 3.0 GHz Takt und mehr (Bedingung: 6 MB Level2-Cache) und alle Core i5-7xx und Core i7 Prozessoren hinein – ergo nahezu ausschließlich HighEnd-Modelle. Allerdings darf natürlich die Frage aufgestellt werden, wie oft eine solche Sequenz in der Praxis wirklich vorkommt, bislang sind von StarCraft II Spielern eigentlich keine besonderen Probleme mit der CPU-Performance gemeldet worden. Andererseits sind Spiele mit einer hohen Anzahl an semi-autonom agierenden Einheiten dafür bekannt, bei voller Ausreizung der Einheiten-Anzahl von einer Grafikkarten- zu einer heftigen CPU-Limitierung wechseln zu können.

Jedoch ist es gerade bei solcherart Spielen dann ärgerlich, daß nicht eine ordentliche QuadCore-Optimierung eingebaut wurde – schließlich lassen sich die Berechungen für die einzelnen Einheiten (zumeist sind dies reine K.I.-Berechnungen) gut parallelisieren, da die Ergebnisse der Berechnungen kaum voneinander abhängen. Sicherlich müssen die Spieledesigner aufpassen, daß sie sich nicht total in QuadCore-Gefilde verrennen – was passiert, wenn das Spiel derart viele Einheiten aufbietet, daß nur noch ein QuadCore-Prozessor (samt QuadCore-Optimierung) diese bewältigen kann. Aber man kann hierbei doch auch Mittelwege gehen, wie im Singleplayer-Spiel die Einheitenanzahl auf DualCore-Prozessoren zu optimieren und im Multiplayer-Spiel die sehr hohen Einheitenanzahlen erst bei Vorhandensein von QuadCore-Prozessoren bei allen Mitspielern freizugeben.

Wie AMD in einem Blog-Beitrag bekanntgegeben hat, werden zukünftige AMD-Prozessoren kein 3DNow! mehr unterstützen. 3DNow! war AMDs Gegenentwurf zu Intels MMX (1997), bevor man später Intels MMX-Nachfolger SSE (samt Weiterentwicklungen) lizensierte und in die eigenen Prozessoren einbaute, womit 3DNow! nicht mehr weiterentwickelt wurde. Dadurch gab es auch nur recht wenige AMD-Prozessoren, die rein nur 3DNow! und nicht SSE unterstützten – nur den K6-2 (1998), den K6-III (1999) und den originalen K7 (1999, "Athlon"), schon ab dem ebenfalls K7-basierten Athlon XP (2001) hatte AMD dann auch SSE mit an Bord. Demzufolge konnte sich 3DNow! auch nie wirklich durchsetzen und wurde schon seit einiger Zeit selbst von AMD nicht mehr empfohlen einzusetzen.

Zu seinen Anfangszeiten gab es aber durchaus gewisse Ausschläge durch 3DNow!: So bezieht sich der Name unserer Partnerseite Planet3DNow! auf diese Technologie, zudem sind eventuell dem einen oder anderen Leser die offiziellen und inoffiziellen 3DNow!-Patches für diverse Spiele basierend auf der Quake2-Engine in Erinnerung, welche seinerzeit eine ganz nette Mehrperformance aus diesen Spielen herausholen konnten. Diese wurden in den Anfangstagen des 3DCenters bei uns gehostet, eine davon (Heretic 2) haben wir sogar selber "erstellt" (reine Kopie der Dateien eines 3DNow!-Patches für ein anderes Spiel, keine Kunst also) – speziell dies war sogar noch vor dem offiziellen Start des 3DCenters im Oktober 1999 und läßt sich damit noch nicht einmal mittels eines Archiveintrags belegen ;).

Die neueste, vielbeachtete Windows-Sicherheitslücke (Heise Security & Spiegel) ist leider nicht so einfach zu erfassen, weil die aktuellen Beschreibungen zu dieser ziemlich ungenau sind. Anscheinend geht es aber schlicht darum, daß bei der Ausführung einer nicht auf dem eigenen Rechner, sondern im Netzwerk oder im Internet liegenden Datei die für diese Datei verknüpften DLLs nicht vom eigenen PC ausgeführt werden, sondern vom exakten Ort der Datei – also im Netzwerk oder Internet (letzteres via WebDAV). Da es keine weiteren Sicherheitssperren gibt, kann damit auch eine mit Schadcode präparierte DLL mit aktuellen Benutzerrechten ausgeführt werden. Praktische Anwendungsfälle könnten die gestreamte MP3 oder aber das mit dem Browser direkt geöffnete PDF-File sein – wobei derzeit nicht klar ist, welche Programme nun betroffen sind, denn jedes einzelne Programm kann dieses DLL-Nachladen anders handhaben.

Vorwiegend soll es wohl um nicht-Microsoft-Programme handeln, wobei derzeit noch nicht einmal sicher ist, unter welchen Windows-Versionen dieser Fehler überhaupt vorkommt. Unabhängig davon scheint uns das ganze aber weniger denn ein Fehler als eine Designentscheidung zu sein – aus welchem der ständige Drang Microsofts hervorschaut, den eigenen PC möglichst vollständig mit dem Internet zu verbinden (besser: den PC ins Internet zu vereinnahmen). Bei einer sauberen, auf größtmögliche Sicherheit setzenden Windows-Programmierung würde so etwas jedenfalls nie vorkommen können, weil das Betriebssystem dann automatisch – ganz unabhängig vom Fehlverhalten einiger Programme – das Nachladen von so gefährlichen Dateien wie DLLs aus anderen Quellen als dem eigenen PC verhindern würde. Davon abgesehen gibt es einen Registry-Eintrag, welcher sich als möglicher Hotfix anbietet – damit kann man verschiedene Verzeichnisse aus der Suche nach benötigten DLLs ausschließen. Ob das durchgehend funktioniert, kann allerdings nur Microsoft sagen.

Shortcuts: TweakPC haben weiterhin die neueste Konsolentechnik auf der Gamescom ausprobiert: Die Xbox360-Bewegungssteuerung Kinect war dabei ein totaler Reinfall, weil es schon an der Erkennung der Testpersonen scheiterte. Der 3D-Effekt des Nintendo 3DS kam dagegen gut an, auch der Heise Newsticker gab gute Wertungen für den Nintendo-Handheld ab. Und zum Abschluß noch etwas ganz abgedrehtes: Laut der Futurezone will sich die mexikanische Stadt Leon zur Kriminalitätsbekämpfung flächendeckend mit Irisscanner ausrüsten, welche alle Passanten scannt und automatisch mit dem Polizeicomputer abgleicht – Minority Report läßt grüßen. Zwar darf die Leistungsfähigkeit heutiger Irisscanner für einen solchen Einsatz bezweifelt werden, aber dennoch scheint die Sache kein Fake zu sein, sondern einer realen Planung zu entspringen, die in den nächsten Jahren umgesetzt werden soll.