Anti-Jammer-Thread

[antisteo]

Haben wir schon Weihnachten?

http://www.heise.de/newsticker/meldung/ ... 57164.html

[Krishty]

Haben Mobilcomputer also endlich die Größe, Komplexität, und Software-Qualität erreicht, dass sich RISC nicht mehr lohnt? Arme Welt.

OKOK; damit alle verstehen, worum es geht:

ARM hat afaik (Besserwisser erwünscht) RISC-Maschinen produziert; also Maschinen, deren Befehlssatz im Gegensatz zu Desktop-CPUs klein war. Ganz plattes Beispiel: Während eine Desktop-CPU Operationen für Addition, Negierung, und Subtraktion hat, hat eine RISC-CPU nur Operationen für Addition und Negierung, weil sich die Subtraktion durch Addition und Negierung emulieren lässt.

Will man eine CPU schneller machen, kann man am einfachsten den Takt erhöhen. Das ist aber langfristig eine Sackgasse (wir erinnern uns ja alle noch an die frühen 2000er, als sie den Pentium-4-Kern gegen 7 GHz getaktet haben, und es dann doch lieber sein gelassen haben): Taktet man die CPU doppelt so hoch, zieht sie vier Mal so viel Strom. Wir sehen, dass man da mit Verbrauch und Wärmeentwicklung gegen eine Wand rennt.

Darum sind in den letzten Jahren die CPUs nicht mehr schneller, sondern größer geworden: Verbaut man zwei Kerne statt einem, hat man theoretisch die doppelte Leistung, aber auch nur den doppelten Verbrauch (gegenüber dem Vierfachen eines doppelten Takts). Verbaut man eine zusätzliche Befehle in die CPU, wird die zwar größer, aber schafft mehr pro Takt (im Beispiel oben eine Subtraktion in einem Takt statt in zwei für Negierung und Addition). Wir wissen ja alle, wie viel schneller man Mathe durch SSE kriegt, weil die CPU dann breiter operiert als auf Skalaren. Da habe ich auch nichts gegen; so weit, so gut.

Aber auch damit kam man irgendwann nicht weiter: Darum baut man so Sachen ein wie Sprungvorhersage, Out-of-Order-Ausführung, schnelle Zugriffe auf nicht ausgerichtete Speicherbereiche, µOp-Cache, und den ganzen anderen Kram. Das Besondere an diesen Optimierungen ist, dass sie die Verfehlungen des Maschinentextes glätten indem sie den Kram auseinandernehmen und optimiert wieder zusammenstecken, bevor die CPU sie ausführt. Das ist bei Desktop-CPUs seit Jahren die Hauptmethode, um noch Leistung zu gewinnen.

Kurz: Die zusätzlichen Transistoren biegen alles wieder gerade, was Befehlssatzarchitektur, Programmierer, und Compiler verkackt haben. Auf Desktop-CPUs spielt das keine Rolle, weil die Software eh Schrott ist und die CPUs sowieso zig hundert Watten saugen und nur Leistung, Leistung, und nochmal Leistung bringen sollen. Aber wenn man jetzt bei Mobilarchitekturen, mit durchdachten statt gewucherten Befehlssätzen, Transistoren dafür raushaut, dann finde ich das bedenklich. Und wenn man damit auch noch gewaltig Leistung gewinnt, ist das meiner Meinung nach nur ein Armutszeugnis für die Software- und Compiler-Qualität der ganzen Branche (denn ein Programm, das für die Ziel-Pipeline optimiert wäre, würde durch OoOE überhaupt nicht schneller). Aber vielleicht habe ich auch einfach nichts aus Itanium gelernt.

[Alexander Kornrumpf]

Also fefe, falls du es nicht gelesen haben solltest und ich es richtig verstanden habe, hat das so interpretiert, dass die Intel Desktop CPUs in Zukunft weniger Strom ziehen werden.

Das was du hier bemägelst scheint er als Naturkonstante einfach angenommen zu haben (a la "gelohnt" hat sich ARM nie, es hat nur wenig Strom gezogen).

Du vergleichst eine Welt in der die Leute auf ARM optimiert haben weil der Prozessor langsam war mit einer in der man das nicht mehr "muss".

Fefe vergleicht eine Welt in der die Software langsam lief weil der Prozessor langsam war mit einer in der sie schnell(er) läuft.

Wie gesagt, falls ich das nicht missverstehe...

[Lynxeye]

[...]
Aber auch damit kam man irgendwann nicht weiter: Darum baut man so Sachen ein wie Sprungvorhersage, Out-of-Order-Ausführung, schnelle Zugriffe auf nicht ausgerichtete Speicherbereiche, µOp-Cache, und den ganzen anderen Kram. Das Besondere an diesen Optimierungen ist, dass sie die Verfehlungen des Maschinentextes glätten indem sie den Kram auseinandernehmen und optimiert wieder zusammenstecken, bevor die CPU sie ausführt. Das ist bei Desktop-CPUs seit Jahren die Hauptmethode, um noch Leistung zu gewinnen.

Kurz: Die zusätzlichen Transistoren biegen alles wieder gerade, was Befehlssatzarchitektur, Programmierer, und Compiler verkackt haben. [...]

Hier bist du leicht unfair.
Ja, Compiler sind immer noch meilenweit hinter dem Zustand in dem man sie sich wünschen würde, allerdings sind viele der Dinge welche OoO Execution & Co gerade biegen nicht nur Compilerverfehlungen. Ich jedenfalls möchte nicht jedes Programm für genau die Pipeline eines Prozessors compilieren müssen. Auf den ARMs ist es schon ein genügend großer Aufwand für jede Inkarnation des Befehlssatzes neue Binaries zu bauen, ich möchte nicht noch für jeden Implementer des Befehlssatzes ein eigenes Binary haben. Da hätte ich also gern OoO um ein klein wenig flexibler zu sein.

Harwarebeschleunigte unaligned Loads/Stores haben auch ihre Berechtigung. Sieh dir die ganzen neuen superschnellen Komprimierungsalgorithmen wir snappy und LZ4 an, welche an der Schallmauer der RAM-Geschwindigkeit kratzen. Ohne unaligned Load/Store wäre der Text in den innersten Schleifen viel größer und die Performance würde extrem einbrechen.

µOP Cache sind auch allgemein hilfreich, die Dekoder sind, unabhängig ob nun ARM oder x86, einer der größten Energieschlucker der CPU. Wenn ich diese für die Laufzeit einer Schleife abschalten kann, weil alles noch im Tracebuffer liegt, gewinne ich beim Stromverbrauch einiges.

[kaiserludi]

welche an der Schallmauer der RAM-Geschwindigkeit kratzen..

Da fällt mir doch glatt auf: Dem Forum fehlt eindeutig ein Thread, in dem die schönsten Formulierungen des Forums gesammelt werden :D

[Krishty]

Also fefe, falls du es nicht gelesen haben solltest und ich es richtig verstanden habe, hat das so interpretiert, dass die Intel Desktop CPUs in Zukunft weniger Strom ziehen werden.

Desktops werden aber hoffentlich nicht mit den dort vorgestellen Tablet-CPUs arbeiten! Außerdem sprach ich mit antisteo statt fefe.

Du vergleichst eine Welt in der die Leute auf ARM optimiert haben weil der Prozessor langsam war mit einer in der man das nicht mehr "muss".

Fefe vergleicht eine Welt in der die Software langsam lief weil der Prozessor langsam war mit einer in der sie schnell(er) läuft.

Schneller und sparsamer werden die CPUs aber schon allein durch neue Fertigungstechnologien. Das meiste, was Intel da vorgestellt hat, ist jedenfalls nicht dem Stromverbrauch zuträglich sondern nur dazu da, sich möglichst schnell in diesem Bereich breitzumachen indem man erträglich schnelles x86 anbietet (wie schon damals bei den Netbooks) und damit den Programmierern eine Last abnimmt (und sie so noch schlechtere, ältere, und – vor allem – billigere Software anbieten lässt).

Kurz: Die zusätzlichen Transistoren biegen alles wieder gerade, was Befehlssatzarchitektur, Programmierer, und Compiler verkackt haben.

Hier bist du leicht unfair.
Ja, Compiler sind immer noch meilenweit hinter dem Zustand in dem man sie sich wünschen würde, allerdings sind viele der Dinge welche OoO Execution & Co gerade biegen nicht nur Compilerverfehlungen. Ich jedenfalls möchte nicht jedes Programm für genau die Pipeline eines Prozessors compilieren müssen. Auf den ARMs ist es schon ein genügend großer Aufwand für jede Inkarnation des Befehlssatzes neue Binaries zu bauen, ich möchte nicht noch für jeden Implementer des Befehlssatzes ein eigenes Binary haben. Da hätte ich also gern OoO um ein klein wenig flexibler zu sein.

Du möchtest also statische Arbeit, die theoretisch Compiler und Entwickler übernehmen könnten (nämlich das Optimieren auf eine bestimmte Architektur) zur Ausführungszeit durch zusätzliche Transistoren erledigen lassen. Ja gut; das ist eine legitime Meinung (obwohl ich sie nicht teile); nur hat das nicht viel mit Energieeffizienz zu tun und ich möchte das deshalb nicht in meinem Tablet.

Harwarebeschleunigte unaligned Loads/Stores haben auch ihre Berechtigung. Sieh dir die ganzen neuen superschnellen Komprimierungsalgorithmen wir snappy und LZ4 an, welche an der Schallmauer der RAM-Geschwindigkeit kratzen. Ohne unaligned Load/Store wäre der Text in den innersten Schleifen viel größer und die Performance würde extrem einbrechen.

Wie meinen? Wenn der RAM limitiert, ist doch die Menge des Maschinentextes, der drauf wartet, egal? Und nochmal: Damit verbraucht jedes Laden und Speichern, das jemals von irgendeinem Programm durchgeführt wird, vier- bis fünfmal so viel Strom, damit deine einzelne innere Schleife es nicht explizit hinschreiben muss. In meinem Telefon finde ich das nicht wirklich berechtigt.

µOP Cache sind auch allgemein hilfreich, die Dekoder sind, unabhängig ob nun ARM oder x86, einer der größten Energieschlucker der CPU. Wenn ich diese für die Laufzeit einer Schleife abschalten kann, weil alles noch im Tracebuffer liegt, gewinne ich beim Stromverbrauch einiges.

Wäre das Kompilat für die Zielarchitektur kompiliert, entfiele die Übersetzung in µOps komplett und der einzige Stromfresser wäre der Cache. Siehe Itanium, der den Maschinentext direkt an die Recheneinheiten durchgereicht hat.

Der war natürlich eine große Katastrophe; aber der Tablet-Markt ist (zum Glück!) kein Markt, wo man jedes Jahr eine neue CPU einbaut und alle drei Jahre ein neues OS, und sich seine Programme jedes Mal rüberkopiert. Meistens kann man sich die Programme für Pad und Telefon ja nicht einmal ab Werk frei aussuchen und die Hardware-Variation ist Kerneigenschaft statt Exot.

Jedenfalls glaube ich nach allem, was ich bisher von x86 gesehen habe, dass langfristig niemand davon profitiert, dass Telefone nun OoO laufen.

[Schrompf]

Nikis Freude über logarithmische Tiefen und die daraus entstehende Diskussion abgetrennt nach http://zfx.info/viewtopic.php?f=5&t=3025

[Krishty]

Boooooooooaaaaaaah

Vier Jahre lang habe ich Assembly analysiert; habe meine Programme Byte für Byte optimiert

vier lange Jahre

und nachdem mein ganzes Projekt nur noch zwei virtuelle Funktionen beinhaltet, sitze ich nun zum ersten Mal in meinem Leben vor einem Fall, in dem Visual C++ eine virtuelle Funktion geinlinet hat!

Durch einen variablen Zeiger, wo der Optimizer erstmal raffen muss, worauf der verweist!

Und durch drei andere Mini-Funktionen durch auch noch!

Visual C++ kann es!

Ich vermute ganz schlicht, dass das Feature nie zuende getestet wurde, und jetzt, wo ich nur noch eine vtable-lose Basisklasse mit einer einzigen virtuellen Funktion und einer einzigen Implementierung habe, funktioniert es endlich wie gewollt!

Kandidat:

Code: Alles auswählen

ASCIIStreamWriter & operator << (
	ASCIIStreamWriter &	stream,
	UTF16Unit const *	toZeroTerminatedString
) {
	while(L'\0' != *toZeroTerminatedString) {
		auto const output = (128u > *toZeroTerminatedString) ? ASCIICharacter(*toZeroTerminatedString) : ASCIICharacter('?');
		stream << output;
		++toZeroTerminatedString;
	}
	return stream;
}

stream << output; ruft auf:

Code: Alles auswählen

ASCIIStreamWriter & operator << (
	ASCIIStreamWriter &		stream,
	ASCIICharacter const	ASCIICharacter
) {
	stream.append(range(&ASCIICharacter, &ASCIICharacter + 1));
	return stream;
}

stream.append() ist implementiert als:

Code: Alles auswählen

void ASCIIStreamWriter::append(
	Range<ASCIICharacter const> const & output
) {
	assert("invalid output stream bound", nullptr != myToStream);
	return myToStream->append(range(
		reinterpret_cast<Byte const *>(output.toBeginning),
		reinterpret_cast<Byte const *>(output.toEnd)
	));
}

myToStream verweist auf

Code: Alles auswählen

class __declspec(novtable) OutputStream {
public:

	virtual void append(
		Range<Byte const> const &
	) = 0;

};

Die einzige Implementierung der Funktion ist:

Code: Alles auswählen

	void StandardOutputStream::append(
		Range<Byte const> const & output
	) {
		assert("invalid std stream", WinAPI::invalidHandleValue != myHandle);
		assert("std output too long", 0x7FFFFFFF >= sizeOf(output));
		assert("invalid std output", nullptr != output.toBeginning);

		// See http://msdn.microsoft.com/en-us/library/aa365747.
		UnsignedInt4B writtenSize = 0;
		WriteFile(myHandle, toBeginningOf(output), UnsignedInt4B(sizeOf(output)), &writtenSize, nullptr);

		return;
	}

Der entstandene Maschinentext:

Code: Alles auswählen

ASCIIStreamWriter & operator << (
	ASCIIStreamWriter &	stream,
	UTF16Unit const *	toZeroTerminatedString
) {
 push        rbx  
 push        rbp  
 push        rdi  
 sub         rsp,30h  
	while(L'\0' != *toZeroTerminatedString) {
 movzx       eax,word ptr [rdx]  
 xor         ebp,ebp  
 mov         rbx,rdx  
 mov         rdi,rcx  
 cmp         bp,ax  
 je          operator<<+7Fh (0140006C0Fh)  
 mov         qword ptr [rsp+60h],rsi  
		stream << output;
 lea         rcx,[stream]  
 lea         rsi,[rsp+51h]  
 mov         qword ptr [rsp+68h],r14  
 mov         r14d,80h  
 sub         esi,ecx  
		auto const output = (128u > *toZeroTerminatedString) ? ASCIICharacter(*toZeroTerminatedString) : ASCIICharacter('?');
 cmp         r14w,ax  
 jbe         operator<<+3Fh (0140006BCFh)  
 movzx       eax,byte ptr [rbx]  
 jmp         operator<<+41h (0140006BD1h)  
 mov         al,3Fh  
		stream << output;
 mov         rcx,qword ptr [rdi]  
 mov         byte ptr [stream],al  
 lea         r9,[toZeroTerminatedString]  
 mov         rcx,qword ptr [rcx+8]  
 lea         rdx,[stream]  
		stream << output;
 mov         r8d,esi  
 mov         dword ptr [toZeroTerminatedString],ebp  
 mov         qword ptr [rsp+20h],rbp  
 call        qword ptr [__imp_WriteFile (01400250D0h)]  
	while(L'\0' != *toZeroTerminatedString) {
 movzx       eax,word ptr [rbx+2]  
		++toZeroTerminatedString;
 add         rbx,2  
 cmp         bp,ax  
 jne         operator<<+34h (0140006BC4h)  
 mov         r14,qword ptr [rsp+68h]  
 mov         rsi,qword ptr [rsp+60h]  
	}
	return stream;
 mov         rax,rdi  
}
 add         rsp,30h  
 pop         rdi  
 pop         rbp  
 pop         rbx  
 ret  

call qword ptr [__imp_WriteFile (01400250D0h)]!!!!

Selbst, wenn ich das __declspec(novtable) wegnehme, klappt es! Da dann zwei Kandidaten für den Aufruf bleiben (der Stub für die pur virtuelle Funktion und die tatsächliche Implementierung), bedeutet das, dass der Optimizer tatsächlich den Typ hinter dem Zeiger gerafft hat. Ich bin baff. Vielleicht ist Visual C++ autistisch? Kann sich nicht selber anziehen, aber Muster in Telefonnummern finden?

[Krishty]

und nachdem mein ganzes Projekt nur noch zwei virtuelle Funktionen beinhaltet, sitze ich nun zum ersten Mal in meinem Leben vor einem Fall, in dem Visual C++ eine virtuelle Funktion geinlinet hat!

Man kann das Ganze jetzt noch ad absurdum führen:

Ich habe gemerkt, dass die Funktion immer geinlinet wird.

Der Compiler legt aber grundsätzlich eine nicht-inline-Kopie jeder virtuellen Funktion an, damit an der richtigen Stelle der Virtual Function Table jeder Instanz ein gültiger Zeiger steht. Diese Kopie der Funktion wird niemals aufgerufen, weil die Funktion, wie gesagt, immer geinlinet wurde.

Ich kann nun via __declspec(novtable) erzwingen, dass für die Klasse kein Virtual Function Table angelegt wird. Benutzt wird er sowieso nie, weil die einzige virtuelle Funktion überall geinlinet wurde. Da die vtable die einzige Referenz der nicht geinlineten Funktion war, entfällt die Funktion komplett. Das hört sich popelig an, macht aber selbst bei einem Einzeiler locker 400 Bytes Maschinentext aus.

Ich habe jetzt also eine Klasse, die eine Schnittstelle implementiert ohne dabei ihre Methoden virtuell aufrufen zu lassen; und die nur so lange nicht abstürzt, wie ihre Methoden geinlinet werden. lol

Ich frage mich langsam wirklich, was die sich bei alledem gedacht haben. LTCG könnte locker statisch bestimmen, wann eine vtable nicht referenziert wird, und alle Funktionen selber entfernen. MFC-Projekte würden auf die Hälfte zusammenschrumpfen. Bei gutem Programmentwurf sollte die Situation, in der Visual C++ jetzt steckt (dass man jede vtable opt-outen muss und die ganze Exe voll nicht referenzierter Funktionen ist), überhaupt niemals auftreten. Lächerlich, das alles.

[Chromanoid]

GungHo made $118m in April alone, market cap exceeds Nintendo
Der Spielemarkt ist ein riesengroßes Kasino. Wir sind die Automatenspieler der Spieleindustrie.

Könnte auch in den Jammer-Thread, aber irgendwie zeigt es auch wunderbar warum Spieleentwicklung nicht nur aus unterhaltungskünstlerischer Hinsicht so faszinierend ist.

[CodingCat]

C++14 Draft ist da.

[Schrompf]

Mit 1200 Seiten. Meine Vorfreude hält sich in Grenzen, weil ich ganz ehrlich keine Ahnung habe, was denn nun neu ist.

[CodingCat]

Mit 1200 Seiten. Meine Vorfreude hält sich in Grenzen, weil ich ganz ehrlich keine Ahnung habe, was denn nun neu ist.

Dann empfehle ich die ISO C++ Sprint Meeting Trip Reports von Herb Sutter und Michael Wong (1, 2, 3).

[Krishty]

Wow; Turnitin.com indiziert ZFX.

Vielleicht sollten wir uns langsam überlegen, unter welcher Lizenz der Inhalt dieser Seite zur Verfügung gestellt wird – was ich hier schreibe, veröffentliche ich grundsätzlich gemeinfrei und sporne Kopien an. Also nicht, dass mal jemand auf den Deckel bekommt, weil er Quelltext aus meinen Jammer-Beiträgen kopiert hat …

[TDK]

Ich bin so stolz auf mich, was mein neuer Speichermanager alles ermöglicht.

Anstatt mir dauernd temporäre Dateien anlegen zu lassen, um wegwerf-Müll zwischenzuspeichern, habe ich mir nun eine Klasse memory_file entwickelt, die das alles auch im RAM regeln kann. Das System ist sogar so erweitert, dass ich auch gleich eine Datei von der Platte lesen kann bzw. speichern kann. Endlich habe ich eine Klasse für alles! Danke Gott, der mir Hirn verschafft hat.

[antisteo]

Ich bin so stolz auf mich, was mein neuer Speichermanager alles ermöglicht.

Anstatt mir dauernd temporäre Dateien anlegen zu lassen, um wegwerf-Müll zwischenzuspeichern, habe ich mir nun eine Klasse memory_file entwickelt, die das alles auch im RAM regeln kann. Das System ist sogar so erweitert, dass ich auch gleich eine Datei von der Platte lesen kann bzw. speichern kann. Endlich habe ich eine Klasse für alles! Danke Gott, der mir Hirn verschafft hat.

Dazu gibt es aber schon Memory Mapping und sonstige Mechanismen des Betriebssystems. Wenn du nicht gerade vor einem Win 3.11 im Real Mode sitzt, sollte das auch für dein Betriebssystem verfügbar sein.

[Jonathan]

Wow; Turnitin.com indiziert ZFX.

Vielleicht sollten wir uns langsam überlegen, unter welcher Lizenz der Inhalt dieser Seite zur Verfügung gestellt wird – was ich hier schreibe, veröffentliche ich grundsätzlich gemeinfrei und sporne Kopien an. Also nicht, dass mal jemand auf den Deckel bekommt, weil er Quelltext aus meinen Jammer-Beiträgen kopiert hat …

Ich sehe es schon kommen, dass in 2 Jahren irgendjemand hier aus dem Forum gefeuert wird, weil er seinen eigenen Code, den er irgendwann mal unter einem Pseudonym hier veröffentlicht hat, für irgendetwas benutzt hat, was dann als Plagiat abgestempelt wird...

Andererseits: Wenn man korrekt gearbeitet hat, wird man das im Zweifelsfalle auch ganz gut belegen können - vielleicht muss man nicht vor jeder neuen Technik Angst haben.

[Krishty]

Windows 8 bietet in allen Editionen einen virtuellen Adressraum von 128 GiB. Windows 7 Home Premium bot nur 16 GiB (die fettesten Ausführungen boten auch 192 GiB; nun 512). Memory-map ALL files!!!

[Schrompf]

Ich habe gerade den letzten Feinschliff am Splatter-Abspann angebracht. Gibt immernoch unendlich viel zu tun, aber so langsam kommt alles zusammen.

Ich habe am Ende übrigens auf zfx.info verwiesen, falls jemand "Interesse an der technischen Seite der Spielentwicklung" hat. Weil ich euch alle so lieb hab. Und euch ganz ehrlich für weiterempfehlenswert halte.

[Artificial Mind]

[youtube]Irf-HJ4fBls[/youtube]
Es ist wieder diese Zeit des Jahres :) (Anti-Jammer wegen Unterhaltungswert ;) )

[joggel]

Die meinen das wirklich ernst.
Die waren auch letztes Jahr auf der Intergeo und hatten dort einen Stand...

[Schrompf]

Nunja, für Point Clouds wären sie mit ihrer Technologie ja wirklich geeignet. Wirklich große Datenmengen, alles schön statisch, keinerlei weiterführendes Shading notwendig. Der ganze Rest ist durchaus denkbar - ein schlaues Indexing ist dann alles, was Du brauchst.

[Alexander Kornrumpf]

Nunja, für Point Clouds wären sie mit ihrer Technologie ja wirklich geeignet. Wirklich große Datenmengen, alles schön statisch, keinerlei weiterführendes Shading notwendig. Der ganze Rest ist durchaus denkbar - ein schlaues Indexing ist dann alles, was Du brauchst.

Wenn es ein Scam wäre, würde es ja ziemlich schnell auffliegen sobald sie ein Produkt in der realen Welt verkaufen.

[joggel]

Ich kann mir auch schwer vorstellen aus einer beliebigen Punktwolke, komplexe Geometrie (also Polygone) zu generieren. Mit einer zusätzlichen nachbearbeitung oder so etwas wäre das vlt. möglich. Dann könnte man vlt. aus einer Punktwolke solche Grafiken generieren, wie diese Insel, aus den ersten Videos.... halt mit cleveren Indexing oder ähnlichem...

[Chromanoid]

Muss ne ziemlich coole Indexstruktur sein, wenn das wirklich so funktioniert. Mmh das mit dem schnell über Netzwerk Laden lässt mich an Bloomfilter denken.

[dot]

Ich glaub, wie schon damals, als die ihr erstes Video rausgebracht haben, gesagt, dass diese clevere Indexstruktur dem Rest der Welt als "Sparse Voxel Octree" bekannt ist und dass die kaum was anderes machen, als Beamtracing in den Octree. Nun haben sie ihre perfekte Nische gefunden; an Arroganz könnten sie wohl immer noch etwas zurückdrehen, aber ist ja zumindest schonmal viel besser als noch vor ein paar Jahren...

[antisteo]

Könnte man nicht einfach herausfinden, was ihre Indexstruktur ist, indem man einen Renderer schreibt, der exakt diese Artifakte wie im Video erzeugt? Dann sieht man ja, was davon Fake ist und wie hoch der Preis für die flüssige Darstellung ist.

[Chromanoid]

Könnte man nicht einen Sparse Voxel Octree mit einem Bloomfilter (bzw. mehreren) kombinieren um Pfaddurchwanderungen im Vorhinein zu filtern, das müsste doch recht gut funktionieren um einen Großteil der Abfragen, die durch leeren Raum gehen auszuschließen.

Ah hier steht was ich meine (3D Abfragen per Bloomfilter lösen, nicht die o.g. Kombination): http://www.cse.buffalo.edu/~jcorso/pubs ... _bloom.pdf

[antisteo]

Könnte es sein, dass die für jede mögliche Betrachtungsposition gecachet haben, in welcher Entfernung das erste sichtbare Hindernis für jede Sichtrichtung erscheint?

[Chromanoid]

Ich glaube das würde dann aber einen immensen Anstieg der Datenmenge bedeuten...