Hi again, I've uploaded a reformatted results file (and an Excel sheet in case that's interesting) that show the results side by side.
Best, Michael > Am 02.05.2016 um 10:38 schrieb Michael Haupt <michael.ha...@oracle.com>: > > Hi Jochen, > > thanks for clarifying. I've added results from running the benchmarks on an > the unpatched JDK 9 base (see the CR link). The twisti and plevart patches > perform better for large numbers of classes and class values; the mhaupt > patch is weaker than the baseline in those settings. > > As pointed out in my reply to Rémi, I'm very much in favour of using > Christian's patch too. > > Best, > > Michael > >> Am 29.04.2016 um 19:14 schrieb Jochen Theodorou <blackd...@gmx.org >> <mailto:blackd...@gmx.org>>: >> >> Hi, >> >> there was not really any misunderstanding, just that some optimizations have >> to be considered carefully. I am no JDK reviewer, so I can give only my >> opinion as a user. But I am missing a comparison with the unpatched version. >> Comparing the given results and considering the size of the patches and that >> they might have to be reconsidered later on would lead me to prefer the >> twisti version actually. But since I am missing the compare with the >> unpatched version I cannot really judge the performance penalty a resize of >> the map will without doubt introduce. >> http://cr.openjdk.java.net/~mhaupt/8031043/benchmark/ClassValueBench.java >> <http://cr.openjdk.java.net/~mhaupt/8031043/benchmark/ClassValueBench.java> >> contains some numbers, but I cannot tell if they compare or not. At least it >> does not contain the numbers I would expect >> >> bye Jochen >> >> On 29.04.2016 15:21, Michael Haupt wrote: >>> Hi Jochen, >>> >>>> Am 29.04.2016 um 14:42 schrieb Jochen Theodorou <blackd...@gmx.org >>>> <mailto:blackd...@gmx.org> >>>> <mailto:blackd...@gmx.org <mailto:blackd...@gmx.org>>>: >>>> On 29.04.2016 13:19, Michael Haupt wrote: >>>>> Hi Jochen, >>>>> >>>>>> Am 29.04.2016 um 12:17 schrieb Jochen Theodorou <blackd...@gmx.org >>>>>> <mailto:blackd...@gmx.org> >>>>>> <mailto:blackd...@gmx.org <mailto:blackd...@gmx.org>> >>>>>> <mailto:blackd...@gmx.org <mailto:blackd...@gmx.org>>>: >>>>>> my fear is a bit that having only a single value, will not be enough >>>>>> if you have for example multiple dynamic languages running... let's >>>>>> say Nashorn, JRuby, and Groovy. Also, if I ever get there, using >>>>>> multiple values would become a normal case in Groovy. >>>>>> >>>>>> So any size depending optimization looks problematic for me >>>>> >>>>> I may misunderstand you here - note the patch does not introduce a >>>>> single-value *only* ClassValue. The patch is meant to introduce a >>>>> special case for as long as there is only one value associated with a >>>>> class. As soon as a second value comes in, the ClassValue will >>>>> transition to the usual map storage. >>>>> >>>>> Please let me know if this is a response to your concern. >>>> >>>> how does performance compare to cases of 2-12 values? >>> >>> OK, I'm still not sure if there was a misunderstanding or not, and >>> whether my response has clarified that. Please let me know. >>> >>> To answer your question, see the numbers reported in >>> http://cr.openjdk.java.net/~mhaupt/8031043/bench-results.txt >>> <http://cr.openjdk.java.net/~mhaupt/8031043/bench-results.txt> - I'm not >>> going to quote them in full detail here, but overall the numbers for 2, >>> 4, and 16 values are on par for the randomGenerator and >>> sequentialGenerator benchmarks, and show slightly better performance (on >>> the order of 1ns) for the twisti and plevart patches. >>> >>> Best, >>> >>> Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
