Seite 34 von 69
Re: Anti-Jammer-Thread
Verfasst: 07.05.2013, 08:33
von antisteo
Re: Anti-Jammer-Thread
Verfasst: 08.05.2013, 08:00
von 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.
Re: Anti-Jammer-Thread
Verfasst: 08.05.2013, 09:13
von 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...
Re: Anti-Jammer-Thread
Verfasst: 08.05.2013, 09:51
von Lynxeye
Krishty hat geschrieben:[...]
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.
Re: Anti-Jammer-Thread
Verfasst: 08.05.2013, 11:06
von kaiserludi
Lynxeye hat geschrieben: 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
Re: Anti-Jammer-Thread
Verfasst: 08.05.2013, 18:55
von Krishty
Alexander Kornrumpf hat geschrieben: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.
Alexander Kornrumpf hat geschrieben: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).
Lynxeye hat geschrieben:Krishty hat geschrieben: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.
Lynxeye hat geschrieben: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.
Re: Anti-Jammer-Thread
Verfasst: 10.05.2013, 12:49
von Schrompf
Nikis Freude über logarithmische Tiefen und die daraus entstehende Diskussion abgetrennt nach
http://zfx.info/viewtopic.php?f=5&t=3025
Re: Anti-Jammer-Thread
Verfasst: 12.05.2013, 13:13
von 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?
Re: Anti-Jammer-Thread
Verfasst: 12.05.2013, 22:51
von Krishty
Krishty hat geschrieben: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.
Re: Anti-Jammer-Thread
Verfasst: 13.05.2013, 20:39
von Chromanoid
GungHo made $118m in April alone, market cap exceeds Nintendo
Der Spielemarkt ist ein riesengroßes Kasino. Wir sind die Automatenspieler der Spieleindustrie.
![](/app.php/senky/httpproxy/a1a57bca4840ce2dd453a54d9af4a3d904c7bb4b/687474703a2f2f6169732e62616469736368652d7a656974756e672e64652f70696563652f30322f33342f31362f31372f33363936373935392e6a7067?sid=af8b74a62114f4d2ca488e31520a2f65)
Könnte auch in den Jammer-Thread, aber irgendwie zeigt es auch wunderbar warum Spieleentwicklung nicht nur aus unterhaltungskünstlerischer Hinsicht so faszinierend ist.
Re: Anti-Jammer-Thread
Verfasst: 16.05.2013, 10:07
von CodingCat
Re: Anti-Jammer-Thread
Verfasst: 16.05.2013, 10:39
von Schrompf
Mit 1200 Seiten. Meine Vorfreude hält sich in Grenzen, weil ich ganz ehrlich keine Ahnung habe, was denn nun neu ist.
Re: Anti-Jammer-Thread
Verfasst: 16.05.2013, 10:48
von CodingCat
Schrompf hat geschrieben: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).
Re: Anti-Jammer-Thread
Verfasst: 19.05.2013, 14:12
von 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 …
Re: Anti-Jammer-Thread
Verfasst: 19.05.2013, 23:49
von 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.
Re: Anti-Jammer-Thread
Verfasst: 20.05.2013, 22:34
von antisteo
TDK hat geschrieben: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.
Re: Anti-Jammer-Thread
Verfasst: 22.05.2013, 00:39
von Jonathan
Krishty hat geschrieben: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.
Re: Anti-Jammer-Thread
Verfasst: 22.05.2013, 19:05
von 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!!!
Re: Anti-Jammer-Thread
Verfasst: 24.05.2013, 12:21
von 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.
Re: Anti-Jammer-Thread
Verfasst: 28.05.2013, 21:10
von Artificial Mind
[youtube]Irf-HJ4fBls[/youtube]
Es ist wieder diese Zeit des Jahres :) (Anti-Jammer wegen Unterhaltungswert ;) )
Re: Anti-Jammer-Thread
Verfasst: 28.05.2013, 21:27
von joggel
Die meinen das wirklich ernst.
Die waren auch letztes Jahr auf der Intergeo und hatten dort einen Stand...
Re: Anti-Jammer-Thread
Verfasst: 28.05.2013, 21:47
von 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.
Re: Anti-Jammer-Thread
Verfasst: 28.05.2013, 21:52
von Alexander Kornrumpf
Schrompf hat geschrieben: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.
Re: Anti-Jammer-Thread
Verfasst: 28.05.2013, 21:59
von 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...
Re: Anti-Jammer-Thread
Verfasst: 28.05.2013, 22:06
von 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.
Re: Anti-Jammer-Thread
Verfasst: 28.05.2013, 22:31
von 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...
Re: Anti-Jammer-Thread
Verfasst: 28.05.2013, 22:54
von 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.
Re: Anti-Jammer-Thread
Verfasst: 28.05.2013, 23:02
von 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
Re: Anti-Jammer-Thread
Verfasst: 29.05.2013, 10:05
von 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?
Re: Anti-Jammer-Thread
Verfasst: 29.05.2013, 13:24
von Chromanoid
Ich glaube das würde dann aber einen immensen Anstieg der Datenmenge bedeuten...