Anti-Jammer-Thread
Re: Anti-Jammer-Thread
http://fedoraproject.org/ <-- freies Betriebssystem
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
- Krishty
- Establishment
- Beiträge: 8250
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
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.
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.
-
- Moderator
- Beiträge: 2114
- Registriert: 25.02.2009, 13:37
Re: Anti-Jammer-Thread
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...
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
- Establishment
- Beiträge: 145
- Registriert: 27.02.2009, 16:50
- Echter Name: Lucas
- Wohnort: Hildesheim
- Kontaktdaten:
Re: Anti-Jammer-Thread
Hier bist du leicht unfair.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. [...]
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.
-
- Establishment
- Beiträge: 467
- Registriert: 18.04.2002, 15:31
Re: Anti-Jammer-Thread
Da fällt mir doch glatt auf: Dem Forum fehlt eindeutig ein Thread, in dem die schönsten Formulierungen des Forums gesammelt werden :DLynxeye hat geschrieben: welche an der Schallmauer der RAM-Geschwindigkeit kratzen..
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
- Krishty
- Establishment
- Beiträge: 8250
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Desktops werden aber hoffentlich nicht mit den dort vorgestellen Tablet-CPUs arbeiten! Außerdem sprach ich mit antisteo statt fefe.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.
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).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.
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:Hier bist du leicht unfair.Krishty hat geschrieben:Kurz: Die zusätzlichen Transistoren biegen alles wieder gerade, was Befehlssatzarchitektur, Programmierer, und Compiler verkackt haben.
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.
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.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.
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.µ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.
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
- Moderator
- Beiträge: 4859
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas Ziegenhagen
- Wohnort: Dresden
- Kontaktdaten:
Re: Anti-Jammer-Thread
Nikis Freude über logarithmische Tiefen und die daraus entstehende Diskussion abgetrennt nach http://zfx.info/viewtopic.php?f=5&t=3025
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
- Krishty
- Establishment
- Beiträge: 8250
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
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:
stream << output; ruft auf:
stream.append() ist implementiert als:
myToStream verweist auf
Die einzige Implementierung der Funktion ist:
Der entstandene Maschinentext:
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?
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;
}
Code: Alles auswählen
ASCIIStreamWriter & operator << (
ASCIIStreamWriter & stream,
ASCIICharacter const ASCIICharacter
) {
stream.append(range(&ASCIICharacter, &ASCIICharacter + 1));
return stream;
}
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)
));
}
Code: Alles auswählen
class __declspec(novtable) OutputStream {
public:
virtual void append(
Range<Byte const> const &
) = 0;
};
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;
}
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
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
- Establishment
- Beiträge: 8250
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Man kann das Ganze jetzt noch ad absurdum führen: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!
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
- Moderator
- Beiträge: 4260
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Anti-Jammer-Thread
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.
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
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Anti-Jammer-Thread
C++14 Draft ist da.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
- Schrompf
- Moderator
- Beiträge: 4859
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas Ziegenhagen
- Wohnort: Dresden
- Kontaktdaten:
Re: Anti-Jammer-Thread
Mit 1200 Seiten. Meine Vorfreude hält sich in Grenzen, weil ich ganz ehrlich keine Ahnung habe, was denn nun neu ist.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
- CodingCat
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Anti-Jammer-Thread
Dann empfehle ich die ISO C++ Sprint Meeting Trip Reports von Herb Sutter und Michael Wong (1, 2, 3).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.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
- Krishty
- Establishment
- Beiträge: 8250
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
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 …
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
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.
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
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.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.
http://fedoraproject.org/ <-- freies Betriebssystem
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
Re: Anti-Jammer-Thread
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...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 …
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.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
https://jonathank.de/games/
- Krishty
- Establishment
- Beiträge: 8250
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
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
- Moderator
- Beiträge: 4859
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas Ziegenhagen
- Wohnort: Dresden
- Kontaktdaten:
Re: Anti-Jammer-Thread
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.
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.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
- Artificial Mind
- Establishment
- Beiträge: 802
- Registriert: 17.12.2007, 17:51
- Wohnort: Aachen
Re: Anti-Jammer-Thread
[youtube]Irf-HJ4fBls[/youtube]
Es ist wieder diese Zeit des Jahres :) (Anti-Jammer wegen Unterhaltungswert ;) )
Es ist wieder diese Zeit des Jahres :) (Anti-Jammer wegen Unterhaltungswert ;) )
Re: Anti-Jammer-Thread
Die meinen das wirklich ernst.
Die waren auch letztes Jahr auf der Intergeo und hatten dort einen Stand...
Die waren auch letztes Jahr auf der Intergeo und hatten dort einen Stand...
- Schrompf
- Moderator
- Beiträge: 4859
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas Ziegenhagen
- Wohnort: Dresden
- Kontaktdaten:
Re: Anti-Jammer-Thread
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.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
-
- Moderator
- Beiträge: 2114
- Registriert: 25.02.2009, 13:37
Re: Anti-Jammer-Thread
Wenn es ein Scam wäre, würde es ja ziemlich schnell auffliegen sobald sie ein Produkt in der realen Welt verkaufen.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.
Re: Anti-Jammer-Thread
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...
Zuletzt geändert von joggel am 28.05.2013, 22:15, insgesamt 2-mal geändert.
- Chromanoid
- Moderator
- Beiträge: 4260
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Anti-Jammer-Thread
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
- Establishment
- Beiträge: 1734
- Registriert: 06.03.2004, 18:10
- Echter Name: Michael Kenzel
- Kontaktdaten:
Re: Anti-Jammer-Thread
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
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.
http://fedoraproject.org/ <-- freies Betriebssystem
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
- Chromanoid
- Moderator
- Beiträge: 4260
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Anti-Jammer-Thread
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
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
Zuletzt geändert von Chromanoid am 29.05.2013, 13:46, insgesamt 2-mal geändert.
Re: Anti-Jammer-Thread
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?
http://fedoraproject.org/ <-- freies Betriebssystem
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
- Chromanoid
- Moderator
- Beiträge: 4260
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Anti-Jammer-Thread
Ich glaube das würde dann aber einen immensen Anstieg der Datenmenge bedeuten...