Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Stefan Reuther Newsgroups: de.comp.security.misc Subject: Re: Vertraegliche Sonderzeichen Date: Sun, 27 Dec 2020 12:04:13 +0100 Lines: 90 Message-ID: References: <5fd6b53d$0$32756$7b62cf90@news1.net.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net HSIe854WVCUjDldOw4xHOwo68vxassPnIOROSmac9Il+cl+o0L Cancel-Lock: sha1:hV+YlNYjeN2s4MJJjZZaZibllg0= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 Hamster/2.1.0.1538 In-Reply-To: Xref: csiph.com de.comp.security.misc:33159 Am 26.12.2020 um 10:53 schrieb Bonita Montero: >>> Ja, aber die haben nicht den Pferdefuß der Referenz-Semantik von Java >>> und C#, wobei C# noch Wert-Typen bzw. structs hat, was oft einen wesent- >>> lichen unterschied in der Performance macht. > >> Die Referenzsemantik macht insofern einen wesentlichen Unterschied in >> der Performance als dass der durchschnittliche C++-Programmierer alles >> per Referenz übergibt, weil er das für schneller hält (und weil ihm >> "hilfreiche" Tools entsprechende Warnungen geben). > > Die Referenz-Semantik bedingt, dass jedes Objekt einen eigenen Block > auf dem Heap belegt, was eine geringere Lokalität der Zugriffe verur- > sacht. Desweiteren können Operationen im Speicher dadurch nicht OoO > -parallelisiert werden weil Operationen die sonst bei Objekten die > in-line im Speicher lägen hinter einem Zeiger-Zugriff liegen, was > die Operations-Reihenfolge serialisiert. An welcher Stelle ist das denn relevant? Die Operationen, die typischerweise parallelisiert werden, sind Operationen auf Vektoren/Matrizen von numerischen Daten, die liegen selbstverständlich auch in Java linear hintereinander. > Desweiteren gibt's noch > die Kosten einer Garbage-Collection, die extrem hoch sind, weswegen > nach Chris Lattner (ehemaliger LLVM- und Swift-Entwickler) ein gar- > bage-collecteter Heap erst beim drei bis vierfachen Speicherverbrauch > eines üblichen Heaps dessen Performance erreicht. Es gibt Code, der mit GC schneller ist, und welchen, der mit GC langsamer ist, und mit mehr Speicher kann man sich seltenere (also im Endeffekt billigere) GC erkaufen. Speicher ist billig. >> Und dann hat der arme C++-Compiler das Problem des möglichen Aliasing, >> worüber ein Java-JIT nur müde lächelt. > > Wird in C / C++ selten zum Problem. Das wird eigentlich immer zum Problem, weil eben ein for (size_t i = 0; i < n; ++i) c[i] = a[i] * b[i]; nicht parallelisiert werden kann, da a, b und c beliebig aliasen können. In Java ist das kein Problem. >> Wenn ich mir z.B. >> https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/pidigits.html >> >> ansehe (hab nur mal flüchtig durchgeklickt) ist der Gewinner ein >> C++-Programm, das 4 Kerne auslastet und gmp benutzt. > > Das ist nur dieser eine Benchmark der ggü. Java so viel besser > parallelisiert ist. Sonst sind die CPU-Auslastungen meistens > vergleichbar: > https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java.html > > Bei revese-complement ist es sogar so, dass der Java-Code besser > parallelisiert, aber C++ trotzdem schneller ist. > >> Und wenn ich mir dann >> https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-gpp-1.html >> >> anschaue: da wird selbstverständlich tief im Dreck gewühlt, das >> Top-C++-Programm operiert mit #ifdef __AVX__, union usw. > > Ja und ? In C++ geht das; in Java nicht. Das ist dann kein C++ mehr. Das ist Assembler mit C++-Syntax. Das 'reverse-complement' ganz besonders. Assembler und eine eigene 'vector'-Implementierung? Hieß es nicht gerade noch, dreckige C-Tricks seien in C++ hier nicht erlaubt? Ebenso, wie man in C++ aus der wohldefinierten Sprache ausbrechen kann, kann man das in Java, indem man ein Assembler-(C-, C++-, Fortran-) Modul per JNI anbindet. >>> Muss ein AOT-Compiler mit Link-Time-Compiling auch nicht. > >> Das halte ich wieder für pure Theorie. > > Das machen alle Compiler mit Link-Time Code Generation. > > Zu meinen Java und C# wären Performance-mäßig konkurrenzfähig ist dumm. Man kann seit über 20 Jahren Java nativ übersetzen (gcj). Stefan