News des 28./29. Juni 2008

Bei NGOHQ [1] hat man es geschafft, einer Radeon HD 3850 eine PhysX-Beschleunigung beizubringen, in deren Folge die Karte ähnliche Performance-Sprünge im GPU-Test von 3DMark Vantage hinlegte wie die nVidia-Karten mit dem Beta-Treiber 177.39. Das Ergebnis ist mit einem CPU-Score von 22.606 auf einer Radeon HD 3850 sogar ausgesprochen gut, eine (deutlich stärkere) GeForce GTX 280 erreicht mit einem CPU-Score von 27.129 [2] auch nicht bedeutsam mehr. Offensichtlich haben NGQHQ irgendwie die Hardware-Erkennung von nVidias CUDA manipuliert – und rein von der Technik her spricht ja nichts dagegen, daß ATI-Beschleuniger auch PhysX ausführen können. Im übrigen soll ATI laut der PC Games Hardware [3] sogar an einem offiziellen PhysX-Support für die aktuellen Radeon-Grafikkarten arbeiten, die entsprechende Lizenz hat man wohl.

Hardwareluxx [4] haben mit der Asus Splendid MA3850M eine ziemlich außergewöhnliche Radeon HD 3850 Grafikkarte im Test, wurde hierbei doch die Mobile-Version des RV670-Grafikchips auf einem MXM [5]-Modul benutzt. Damit ist diese Grafikkarte deutlich kleiner als die Referenzversion der Radeon HD 3850, zudem sinkt auch der Stromverbrauch etwas. Letzteres geschieht jedoch in einem überschaubaren Rahmen (7,6 Watt weniger als eine reguläre Radeon HD 3850, das sind runde 12 Prozent weniger), womit dieser Idee seitens Asus etwas die endgültige Schlagkraft fehlt. Zumindest ist die Performance der Karte gleichwertig zu der einer regulären Radeon HD 3850 – sicherlich in erster Linie dadurch garantiert, daß Asus dieser Karte die originalen Taktraten der Radeon HD 3850 spendiert hat.

Dagegen wird der benutzte Mobile-Chip in seinem natürlichen Umfeld in aller Regel mit geringeren Taktraten ausgestattet und kommt daher dann zumeist auch mit geringeren Chip- und Speicherspannungen aus. Beide Punkte sorgen dann dafür, daß der Stromhunger der Mobile-Varianten deutlich unter dem der Desktop-Pendants liegt. Und wie man am Fall der Asus Splendid MA3850M dann sehen kann, ist es mit dem Stromsparen bei den Mobile-Grafikchips nicht besonders weit her, wenn diese auf Desktop-Taktraten betrieben werden. Was im Umkehrschluß bedeutet: Erstens einmal benötigen ATI und nVidia bei ihren Mobile-Grafikchips derzeit die dort üblichen niedrigeren Taktfrequenzen, um den Stromhunger dieser Chips zu bändigen.

Und zweitens eigenen sich für den Mobile-Einsatz derzeit nur solche Grafikchips, deren Strombedarf sich durch Taktsenkungen, Einheiten-Deaktivierung und niedrigere Spannungen überhaupt in für den Mobile-Einsatz gangbare Bereiche herunterdrücken lassen. Anders formuliert: Die neuen HighEnd-Chips RV770 und GT200 dürften kaum im Mobile-Einsatz zu erleben sein, dafür ist deren Stromhunger einfach zu hoch. Beide Grafikchip-Entwickler dürften sich eher darauf konzentrieren, ihre vorhergehenden HighEnd-Chips breiter ins Mobile-Segment zu bringen: Sofern ATIs RV670 als auch nVidias G92 (insbesondere in dessen 55nm-Version) erscheinen hierfür als derzeit größte gangbare Lösungen – was natürlich den aktuell weiterhin erheblichen Performance-Unterschied zwischen Desktop und Mobile nicht geringer werden läßt.

Beim Hardware-Mag [6] ist man der Frage nachgegangen, ob ein DualChannel-Speicherinterface (auf Mainboards für Intel-Prozessoren) heutzutage eigentlich immer noch benötigt wird. Die entsprechend angestellten Benchmarks gaben dem DualChannel-Speicherinterface nur einen Vorsprung von mageren 2 Prozent – wobei hier anzumerken wäre, daß dies zum Start dieser Technologie nicht maßgeblich besser war, sich der Vorteil des DualChannel-Speicherinterfaces eigentlich immer nur auf unter 10 Prozent belief. Man hat dieses Feature schon seinerzeit immer nur dankend mitgenommen, weil Mainboards ohne DualChannel-Speicherinterface (und ansonsten der gleichen Ausstattung) nicht wirklich günstiger waren/sind.

Auf der anderen Seite stellt der im Test benutzte DDR3/1333-Speicher selbst an einem SingleChannel-Speicherinterface exakt soviel Speicherbandbreite zur Verfügung, wie das FSB1333-Interface des benutzten Intel-Prozessors theoretisch maximal verarbeiten kann [7] – derselbe Speicher an einem DualChannel-Interface ist also ziemlich heftiger Overkill. Was man somit ausgemessen hat, war vielmehr, ob man sich mit der extremen Speicherbandbreite von DDR3-Speicher das DualChannel-Speicherinterface nicht eigentlich sparen kann – was zu bejahren ist. Allerdings hängt dies weniger am Speicherinterface, sondern eben vielmehr an den rasend hohen DDR3-Taktfrequenzen sowie den – vergleichsweise – stagnierenden FSB-Taktungen der aktuellen Intel-Prozessoren.

Aber natürlich ist die Frage eines DualChannel-Speicherinterfaces in einem Mainboard-Chipsatz auch eine Frage nach einer klar auslaufenden Technologie. In AMDs K8- und K10-Prozessoren werkelt schon seit geraumer Zeit ein integrierter Speichercontroller, Intel wird zum Jahresende mit der Nehalem-Prozessorenarchitektur in diesem Punkt nachziehen. Zwar sind auch diese Speichercontroller mehrfach ausgelegt (bei AMD zweifach, bei Intel zwei- bis dreifach), aber auch hier dürfte kaum jemand auf die Idee kommen, auf diesen Effekt (egal wie gering) zu verzichten – günstiger wird es schließlich dadurch nicht. Interessant dürfte allerhöchstens die Frage sein, welche Performance-Differenz es zwischen den mit DualChannel-Interface und den mit TripleChannel-Interface angebundenen Nehalem-Prozessoren gibt, wobei diese Prozessoren aller Wahrscheinlichkeit daneben auch noch andere Hardware-Unterschiede aufweisen werden.

Zur gestern [8] berichteten neuen Bedrohung für den Internet Explorer wären noch ein paar allgemeine Gedanken hinzuzufügen: So kann es mittlerweile zweifelsohne als nervend bezeichnen, wie in letzter Zeit derart oft gravierende Sicherheitslücken aufgedeckt werden, gerade bei Browser-Software. Wir befinden uns nun auch nicht mehr im Jahr 1998, als das Internet-Zeitalter langsam an Fahrt aufnahm, sondern im Jahr 2008, wo sich das Internet nunmehr breit und unangefochten etabliert hat – doch bei der Sicherheit liegen wir weiterhin im Anfängerbereich. Vor allem aber ergibt sich in diesem Punkt anscheinend keine wirkliche Weiterentwicklung, die Sicherheitsprobleme haben ja im Laufe der letzten Zeit nicht ab-, sondern eher zugenommen.

Dies verlangt – gerichtet an die Adresse der Browser-Hersteller – eventuell auch einmal nach generell anderen Lösungen, wo das Sicherheitskonzept und nicht die Benutzerfreundlichkeit im Vordergrund stehen. So sollte die ganze Idee der Scriptsprachen im Browser auf den Prüfstand, denn ohne diese funktionieren 99 Prozent aller Sicherheitslücken nicht mehr. Zudem sollte das Sandbox-Konzept weiterentwickelt werden, im Idealfall sollte ein Browser HTML-Code in einem speziellen Speicherbereich ausführen, welcher ausschließlich "dummes" HTML versteht und auf Scripte und eingeschmuggelten Code (über Buffer-Overruns) gar nicht reagieren kann.

Die Webseiten-Macher müssten sich hierauf natürlich umstellen und Script-Code nicht mehr auf dem Computer des Surfers, sondern auf dem Webserver selber ausführen – was gleichzeitig die Nutzung von Scripten auf dieses Maß reduziert, welches wirklich notwendig ist. Das Ziel wäre ein Browser, welcher eher wie eine Streaming-Maschine funktioniert, aber selber nichts auf dem Computer des Surfers ausführt. Dies kann zwar nie eine hundertprozentige Sicherheit schaffen, aber die größten Einfallstore für Schädlinge beim reinen Surfen fallen hiermit weg. Ob es allerdings eine solche Entwicklung geben wird, wäre arg zu bezweifeln: Software-Hersteller meiden aus Wettbewerbs-Gründen normalerweise alle Einschränkungen bei der Benutzerfreundlichkeit – und Sicherheit kann (da erst einmal nicht real greifbar) schließlich auch per Werbung erschaffen werden.