Anybody wants to look at this logging issue I reported several months ago?
Le 27 juin 2013 11:57, Laurent Bourgès bourges.laur...@gmail.com a
écrit :
Dear members,
I have a problem within an external library using one JVM Shutdown hook
to perform resource cleanup (socket, lock file deletion
Alan,
Thanks for creating the bug 9005822 !
As I spotted in my initial email, both shutdown hook problems (JavaWS and
JUL) are due to the concurrent execution of shutdown hooks :
com.sun.imageio.stream.StreamCloser.java
101: Runtime.getRuntime().addShutdownHook(streamCloser);
), update usage
statistics and manage cache eviction policy (avoid wasting memory)
Please give me your feedback opinion and evaluate if this feature
seems possible to implement into the JDK (hotspot, gc, core-libs) ...
What is the procedure to create such JDK9 RFE ?
Best regards,
Laurent
check elimination or fill / clear intrinsics ...
Who would be interested by this topics ?
Laurent
-- Message transféré --
De : Laurent Bourgès bourges.laur...@gmail.com
Date : 10 févr. 2014 10:24
Objet : Improve large array allocation / gc intrinsics
À : core-libs-dev core-libs-dev
Comments opinions from core-libs, please ?
Laurent
-- Message transféré --
De : Thomas Schatzl thomas.scha...@oracle.com
Date : 11 févr. 2014 11:28
Objet : Re: Fwd: Improve large array allocation / gc intrinsics
À : Laurent Bourgès bourges.laur...@gmail.com
Cc : hotspot
and dirty solution).
I advocate this is not a very clean solution but I prefer efficiency here:
any better solution may be appropriate to avoid at least Integer allocation
and maybe enhance performance.
Best regards,
Laurent Bourgès
PS: here is the patch as text:
# This patch file was generated
On 3/19/13 5:19 AM, Laurent Bourgès wrote:
Dear all,
I run recently netbeans profiler on my swing application
(Aspro2:http://www.jmmc.fr/aspro
) under linux x64 platform and figured out a
performance and waste issue related to PlatformLogger.
Actually, the JavaLogger implementation uses
/contribute/
On 3/20/2013 5:45 AM, Laurent Bourgès wrote:
Hi mandy,
Do you want me to propose an improved patch to remove the former Map and
fix the getLevel() method ? or you prefer fix on your own ?
Is it better to discuss the fix on the bug database (still not visible) ?
Laurent
:
System.gc();
// pause:
try {
Thread.sleep(100l);
} catch (InterruptedException ie) {
}
}
}
2013/3/21 Laurent Bourgès bourges.laur...@gmail.com
Here is an improved patch tested on JDK7u13 and JDK8 internal build on my
machine linux x64:
http
Object level = LoggingSupport.parseLevel(getLevelName(l));
486 levelObjects.put(l, level);
487 }
488 }
I think I did not change the scope of the mapping i.e. PlatformLogger's
levels.
Cheers,
Laurent
2013/3/21 Laurent Bourgès bourges.laur...@gmail.com
Here
...@gmail.com
On 03/21/2013 12:12 PM, Laurent Bourgès wrote:
Here is an improved patch tested on JDK7u13 and JDK8 internal build on my
machine linux x64:
http://jmmc.fr/~bourgesl/**share/webrev-8010309/http://jmmc.fr/%7Ebourgesl/share/webrev-8010309/
FYI, I removed completely the MapInteger
been initialized by application code.
Mandy
On 3/21/2013 7:45 AM, Peter Levart wrote:
On 03/21/2013 03:30 PM, Laurent Bourgès wrote:
Peter,
your solution looks better; I wanted my patch to be simple, efficient and
only modify the JavaLogger class (localized changes).
In your patch, I
:
- added the comments
- made LevelEnum private (to not be tempted to be used from outside the
PlatformLogger)
- used the loggingEnabled flag as a pre-check when trying to parse the
level objects
What do you think?
Regards, Peter
On 03/21/2013 04:06 PM, Laurent Bourgès wrote:
Thanks
05:09 PM, Peter Levart wrote:
You're right, loggingEnabled can change afterwards. I'll correct the code
as suggested...
Peter
On 03/21/2013 04:57 PM, Laurent Bourgès wrote:
Peter,
I am convinced it is better if the LevelEnum belongs to JavaLogger class
(encapsulated so defered
Hi Mandy Peter,
Here is an update patch applying mandy's suggestions:
http://jmmc.fr/~bourgesl/share/webrev-2-8010309/
Good work and I like the solution.
Thanks.
JavaLogger and LoggerProxy are only used from within PlatformLogger.
Wouldn't it be better to declare them private? Their usage
Peter,
You've beaten me! I have been preparing them too ;-) ...
Ok I definitely stop working on the code and let you do it.
I also did some some renames, that I think make the code more consistent:
- LevelEnum - Level (the code is not dependent on
java.util.logging.Level, so the name can
Peter,
that's OK for me and the code is clearer.
What remains is a possible rename from: javaLogger, javaLevel,
JavaLoggerProxy - julLogger, julLevel, JulLoggerProxy if that's the final
decision.
I vote for jul prefix that is more explicit; as I said, java means anything
but not
Hi Peter,
thanks for your microbench tool !
It works well and avoid me to do my own (caliper is a well known one)
I do not know what MethodHandle is but its performance is impressive !
Here are my results (Oracle jdk 1.7_13 vs OpenJDK 8 patched):
java -Xms8m -Xmx8m
JDK 1.7_13
run:
JVM START
the final
decision.
Regards, Peter
On 03/22/2013 01:26 PM, Peter Levart wrote:
On 03/22/2013 11:34 AM, Laurent Bourgès wrote:
Peter,
You've beaten me! I have been preparing them too ;-) ...
Ok I definitely stop working on the code and let you do it.
Ok. I'll make the final touches
Dear all,
First I joined recently the openJDK contributors, and I plan to fix java2D
pisces code in my spare time.
I have a full time job on Aspro2: http://www.jmmc.fr/aspro; it is an
application to prepare astronomical observations at VLTI / CHARA and is
very used in our community (200 users):
Hi Mandy, Peter,
thanks for the review.
I wanted the patch to be small and only in PlatformLogger class without API
change to be easily backported to jdk7u.
Do you think this bug is JDK8 only ?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010309
I submitted another patch concerning
Maybe the local var count could be renamed _count or c to avoid name
conflict with the member count and make the code more readable / obvious.
PS: I like final vars.
Cheers
Laurent
Le 28 mars 2013 07:31, Martin Buchholz marti...@google.com a écrit :
On Wed, Mar 27, 2013 at 4:36 PM, Remi Forax
Dear Mandy Peter,
I will test your patch asap (+ benchmark)
Few comments below:
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8010309/webrev.00/
Please let me know if you don't agree with these changes or you find any
performance issue.
I have retained the part in
);
}
Laurent
2013/3/28 Laurent Bourgès bourges.laur...@gmail.com
Dear Mandy Peter,
I will test your patch asap (+ benchmark)
Few comments below:
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8010309/webrev.00/
Please let me know if you don't agree with these changes
on JDK7 updates ?
Regards,
Laurent
2013/3/28 Peter Levart peter.lev...@gmail.com
On 03/28/2013 10:19 AM, Laurent Bourgès wrote:
the following method in JavaLoggerProxy also caught my eye:
void doLog(Level level, String msg, Object... params) {
if (!isLoggable(level
there is some hotspot magic involved to recognise and intrinsify
this
method, since the source code looks like a plain old for loop.
-phil.
On 3/26/2013 4:00 AM, Laurent Bourgès wrote:
Dear all,
First I joined recently the openJDK contributors, and I plan to fix
java2D pisces code in my spare
Andrea,
It could be very interesting if you could provide some concrete example
about your map server: typical image height / width, shape complexity
(number, size, path sizes ...).
Ideally if you could write a test class (sample) computing a single image
it would be very helpful for me to
in order to tune Pisces automatically depending on the
user work load.
Regards,
Laurent
On 3/29/2013 6:53 AM, Laurent Bourgès wrote:
Phil,
I agree it is a complex issue to improve memory usage while maintaining
performance at the JDK level: applications can use java2d pisces in very
) has to be smart (auto - tune)
- clipping issues (dasher, stroker) and spatial resolution (no cpu/memory
waste)
2013/3/30 Andrea Aime andrea.a...@geo-solutions.it
On Fri, Mar 29, 2013 at 3:16 PM, Laurent Bourgès
bourges.laur...@gmail.com wrote:
Andrea,
It could be very interesting if you
---
604 Arrays.fill(elementData, newSize, size, null);
In performance-critical code I would avoid Arrays.fill because it adds a
bit of overhead (unless it's intrinsified, which I don't think it is).
Last week, I sent few benchmarks I did on array cleaning (zero fill)
comparing
Thanks for your valueable feedback!
Here is the current status of my patch alpha version:
http://jmmc.fr/~bourgesl/share/java2d-pisces/
There is still a lot to be done: clean-up, stats, pisces class instance
recycling (renderer, stroker ...) and of course sizing correctly initial
arrays
Does JavaFX belong to OpenJDK projects
(*openjfx/8http://hg.openjdk.java.net/openjfx/8/)
*?
How do I build the complete OpenJDK (javafx, java web start ...) ?
Laurent
2013/4/3 Alan Bateman alan.bate...@oracle.com
On 28/03/2013 20:16, mandy.ch...@oracle.com wrote:
Changeset: e433ed08b733
Mandy, Peter,
here are my comments:
On 04/04/2013 06:52 AM, Mandy Chung wrote:
Peter, Laurent,
History and details are described below.
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8011380/webrev.00/
I add back the getLevel(int), setLevel(int) and isLoggable(int) methods
somebody have an idea to automatically analyze the JDK code and detect
missing isLoggable statements ...
Regards,
Laurent
2013/4/3 Laurent Bourgès bourges.laur...@gmail.com
Anthony,
could you tell me once it is in the OpenJDK8 repository ?
I would then perform again profiling tests to check
/04/13 15:47, Laurent Bourgès wrote:
Dear all,
I just realized there is another problem with PlatformLogger log
statements:
XBaseWindow:
public boolean grabInput() {
grabLog.fine(Grab input on {0}, this);
...
}
This calls the PlatformLogger.fine( varargs):
public void
Mandy,
I would like to add few performance advices in the PlatformLogger Javadoc:
NOTE: For performance reasons, PlatformLogger usages should take care of
avoiding useless / wasted object creation and method calls related to *
disabled* log statements:
Always use isLoggable(level) wrapping logs
Dear java2d members,
I figured out some troubles in java2d.pipe.AAShapePipe related to both
concurrency memory usage:
- concurrency issue related to static theTile field: only 1 tile is cached
so a new byte[] is created for other threads at each call to renderTile()
- excessive memory usage
, Laurent Bourgès wrote:
Mandy,
I would like to add few performance advices in the PlatformLogger Javadoc:
NOTE: For performance reasons, PlatformLogger usages should take care of
avoiding useless / wasted object creation and method calls related to *
disabled* log statements:
Always use
that are replaced by concrete values only when
the message is really going to be logged. *Since NetBeans 6.9*
Cheers,
Laurent
Mandy
P.S. I'll be pushing the changeset today.
On 4/5/2013 9:02 AM, Laurent Bourgès wrote:
Mandy,
I agree it should be well known; but I fixed several cases in awt/net code
Hi
I started fixing All PlatformlLogger bad usages and I am fixing also many
jul Logger usages without isLoggable ...
That represents a lot of changes and a very boring job.
I think sending a webrew tomorrow.
Laurent
Le 4 avr. 2013 14:08, Laurent Bourgès bourges.laur...@gmail.com a
écrit :
Ok
such shared arrays
static final int INITIAL_ARRAY = 256 + 1;
static final int INITIAL_Y_ARRAY = 2048 + 1;
static final int INITIAL_LARGE_ARRAY = 16384 + 1; // large
Laurent
2013/4/7 Andrea Aime andrea.a...@geo-solutions.it
On Fri, Apr 5, 2013 at 4:32 PM, Laurent Bourgès bourges.laur
differences between Logger /
PlatformLogger to make PlatformLogger API more similar to JUL Logger ?
Laurent
2013/4/8 Peter Levart peter.lev...@gmail.com
On 04/07/2013 07:11 PM, Laurent Bourgès wrote:
Hi
I started fixing All PlatformlLogger bad usages and I am fixing also
many jul Logger usages
Anthony,
here is an updated patch concerning both PlatformLogger and Logger 'bad'
usages:
http://jmmc.fr/~bourgesl/share/webrev-8010297.3/
It impacts now awt, swing, JMX, security, network, and apache xml.
Thanks for the review,
Laurent
2013/4/8 Laurent Bourgès bourges.laur...@gmail.com
Mandy,
first I would like to have the given patch applied to OpenJDK 8 (+ JDK7u)
as it fixes many problems:
- string concatenations
- object creations (Object[] or other objects given as params)
- method calls in log statements
In a second step, I can help somebody migrating JUL usages to
of bounds
Could somebody support me ? ie help me working on these tasks or just to
discuss on Pisces algorithm / implementation ?
Best regards,
Laurent Bourgès
Dear Jim,
I advocated I only looked at the netbeans memory profiler's output: no more
megabytes allocated !
The main question is: how to know how GC / hotspot deals with such small
allocations ? Is there any JVM flag to enable to see real allocations as
does jmap -histo.
Quick questions -
2.6.35.14-106.fc14.x86_64 #1 SMP Wed
Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
2013/4/10 Andrea Aime andrea.a...@geo-solutions.it
On Tue, Apr 9, 2013 at 7:34 PM, Laurent Bourgès bourges.laur...@gmail.com
wrote:
Also, this should be tested on multiple platforms, preferably Linux
Dear Jim,
2013/4/9 Jim Graham james.gra...@oracle.com
The allocations will always show up on a heap profiler, I don't know of
any way of having them not show up if they are stack allocated, but I don't
think that stack allocation is the issue here - small allocations come out
of a fast
On 4/9/13 12:37 AM, Laurent Bourgès wrote:
Mandy,
first I would like to have the given patch applied to OpenJDK 8 (+ JDK7u)
as it fixes many problems:
- string concatenations
- object creations (Object[] or other objects given as params)
- method calls in log statements
This is the patch
AM, Laurent Bourgès wrote:
Dear Jim,
2013/4/9 Jim Graham james.gra...@oracle.com
The allocations will always show up on a heap profiler, I don't know of
any way of having them not show up if they are stack allocated, but I don't
think that stack allocation is the issue here - small
Sergey,
I am not an expert here but just my 50 cents.
This optimization shall take place only if it is really hotspot. But if it
is a really hotspot - probably it would be better to remove these
array/object allocation at all and use plane bytes?
Java2D calls AAShapePipe for each shape
Jim and Sergey,
1/ Here are few benchmarks (based on mapBench again) running several
modified versions of AAShapePipe:
http://jmmc.fr/~bourgesl/share/AAShapePipe/mapBench/
- ref:
1 threads and 20 loops per thread, time: 3742 ms
2 threads and 20 loops per thread, time: 4756 ms
4 threads and 20
Anthony, Mandy,
here the 4th patch:
http://jmmc.fr/~bourgesl/share/webrev-8010297.4/
It only contains awt / swing / net classes that use PlatformLogger (no code
modification).
Laurent
timing / comparison between bench runs.
Regards,
Laurent
2013/4/11 Laurent Bourgès bourges.laur...@gmail.com
Jim and Sergey,
1/ Here are few benchmarks (based on mapBench again) running several
modified versions of AAShapePipe:
http://jmmc.fr/~bourgesl/share/AAShapePipe/mapBench/
- ref:
1
Mandy,
I'd really like to see if we can avoid the boilerplate if
(isLoggable(...)) logger.fine() and help ease of development and I
file a RFE (8012006).
Agreed but there is no easy way to have clear code and performance:
- maybe JDK 8 Supplier may help
- or a shorter syntax:
Anthony,
Here is the updated webrev:
http://jmmc.fr/~bourgesl/share/webrev-8010297.5/
Laurent
2013/4/11 Mandy Chung mandy.ch...@oracle.com
On 4/11/13 8:43 AM, Laurent Bourgès wrote:
I don't understand if I should fix it or not ?
src/solaris/classes/sun/awt/X11/XListPeer.java
Nit
3743,255 3745,111 83,027 3746,031 3828,138 3549,364
3866,612 shp_alllayers_47 4 80 6960,23 6960,948 189,75 6963,533 7150,698
6432,945 7431,541
Linux 64 server vm
JVM: -Xms128m -Xmx128m (low mem)
Laurent
2013/4/14 Andrea Aime andrea.a...@geo-solutions.it
On Tue, Apr 9, 2013 at 3:02 PM, Laurent
Jim,
thanks for having some interest for my efforts !
As I got almost no feedback, I felt quite disappointed and was thinking
that improving pisces was not important ...
Here are ductus results and comparison (open office format):
http://jmmc.fr/~bourgesl/share/java2d-pisces/ductus_det.log
Hi all,
A stupid question:
any ThreadLocal subclass should be marked @Contended to be sure that false
sharing never happens between ThreadLocal instance and any other object on
the heap ?
Laurent
2013/5/9 Peter Levart peter.lev...@gmail.com
Hi Aleksey,
Wouldn't it be even better if just
lived objects but for the
old generation (long lived objects) it is not the case: maybe G1 can
provide different partitioning and maybe take into acccount the thread
affinity ?
Laurent
2013/5/9 Peter Levart peter.lev...@gmail.com
On 05/09/2013 04:59 PM, Laurent Bourgès wrote:
Hi all,
A stupid
be the cause of my problems as I do not know if the
hook thread is still within the application class loader ...
Laurent Bourgès
Dear core-libs members,
I finally succeed in diagnosing my shutdown hook issue in Java Web Start
environment: see Bug ID: 9005822.
Could you please give ma feedback to my questions related to LogManager and
StreamCloser shutdown hooks ?
This library uses java.util.logging to log warnings and
Peter,
I looked at Cleaner by curiosity and it seems to be not catching the oome
from thunk.run !
If oome1 is thrown by thunk.run at line 150 then it is catched at line 157
but your new try/catch block (oome2) only encapsulates the doPriviledge
block.
If this block also throws a new oome2 due
Peter,
Thanks for long and detailled answer.
I know now better why OOME should not happen. However any application may
also use phantom references and the ReferenceHandler thread will call
Cleaner.run () which could catch OOME from the application code
implementing thunk.run (). Am I right ?
Hello,
Joe, I tested your changes in the Marlin renderer as it works well !
> A quick note on the 2d changes, several constants (and a copy from a
> package-private method from java.lang) were used to initialize a double
> value POWER_2_TO_32; this can be accomplished more directly using a
>
t of that, but FWIW i am
> sympathetic to that :-)
>
> I liked this tweet:
>
> https://twitter.com/FioraAeterna/status/926150700836405248
>
>life as a gpu compiler dev is basically just fielding repeated
> complaints that
>"fast math" isn't precise and
Hi,
The Marlin renderer (JEP265) uses few Math functions: sqrt, cbrt, acos...
Could you check if the current JDK uses C2 intrinsics or libfdm (native /
JNI overhead?) and tell me if such functions are already highly optimized
in jdk9 or 10 ?
Some people have implemented their own fast Math like
test this yourself using jitwatch. There is
> no native call overhead.
>
> The standard library does not currently include less accurate but faster
> Math functions, maybe someone else can answer if that is something to be
> considered.
>
> - Jonas Konrad
>
> On 11/09/20
=> 10x slower
- cbrt() is slower than pow(1/3) : 1.1s vs 0.7s => 50% slower
Any plan to enhance these specific math operations ?
Laurent
2017-11-09 14:33 GMT+01:00 Laurent Bourgès <bourges.laur...@gmail.com>:
> I checked in the latest jdk master and both cbrt / acos are NOT in
lues for the same angle ?
It is very useful to compute exact fourrier transform...
It is called sinAndCos(double wrappers) in jafama.
Cheers,
Laurent
Le 9 nov. 2017 17:08, "Andrew Haley" <a...@redhat.com> a écrit :
> On 09/11/17 15:02, Laurent Bourgès wrote:
> > --- test
r dev is basically just fielding repeated
> complaints that
> "fast math" isn't precise and "precise math" isn't fast
>
> as an indication of what we could be getting into :-)
>
> Paul.
>
> > On 9 Nov 2017, at 01:00, Laurent Bourgès <bourges.
Hi,
I am the author of the Marlin renderer, integrated in both java.desktop &
javafx.graphics modules.
I wonder if such core annotations @Stable @ForceInline ... could be allowed
to such openjdk modules in order to improve performance.
Marlin already uses jdk.internal.Unsafe but @Stable looks
//
b) or made any mistake on their indices... tricky.
PS: Please share your updated webrev when possible to rebase my changes.
Regards,
Laurent
Le ven. 9 nov. 2018 à 10:08, Laurent Bourgès a
écrit :
> Hi Vladimir,
>
> Thank you for your attention, you are the Sort Master.
>
>
> Le ve
OpenJDK JMH test suite...
For now, I forked the nearly-optimal-mergesort repository on github:
https://github.com/bourgesl/nearly-optimal-mergesort-code/tree/master/results
Cheers,
Laurent
Le sam. 10 nov. 2018 à 12:49, Laurent Bourgès a
écrit :
> Dear Vladimir & other Java sort experts,
>
hms.
>
Is it publicly available ? If yes, where ?
Cheers,
Laurent
> Понедельник, 12 ноября 2018, 13:06 +03:00 от Laurent Bourgès <
> bourges.laur...@gmail.com>:
>
> Hi,
>
> Do you know if someone has written a complete JMH benchmark suite
> dedicated to Arrays.sort() ?
> with v
pensource repository.
>
> Please let me know if you have questions/comments/improvements.
>
Sure, I will do,
Thanks a lot.
Laurent
> Понедельник, 12 ноября 2018, 14:01 +03:00 от Laurent Bourgès <
> bourges.laur...@gmail.com>:
>
> Dear Vladimir,
>
> No informati
data than in DPQS), but I strongly believe that concentrating efforts
> on testing corner cases performance and integrating RadixSort into JDK
> would yield much better performance than DPQS, at least for int[]
> arrays. Also the implementation is much simpler.
>
> With best regards,
&g
Hi,
I am a scientist and the author of the Marlin renderer, integrated in
OpenJDK.
In this renderer, I needed a fast sort algorithm on small almost sorted
arrays, but more important, to deal with 2 arrays: x values and their
corresponding edge indices (pointer like). I derived my MergeSort class
Hi Vladimir,
>
>>
>> The test suite was described in this paper
>>
>> Jon L. Bentley, M. Douglas McILroy
>> “Engineering a Sort Function”, 1993
>>
>> I use Java version (a little bit extended), see attachment.
>> What you need is to specified sorting classes in IntSorter.java
>> and run
methods are acceptable for you. Then we can discuss
> required changes (if any).
>
Perfect, I started adapting your code and will share soon the link to my
github repo.
> Thank you,
> Vladimir
>
Thank you very much for your first thoughts,
Laurent
> Пятница, 9 ноября 2018, 10:44
nov. 2018 à 08:44, Laurent Bourgès a
écrit :
> Hi,
>
> I am currently testing many sort algorithms to improve the Marlin renderer
> (AA 2D shape rasterizer), I integrated since OpenJDK9 and am still
> improving for OpenJDK12 .
>
> I created my MergeSort (top down, check fo
Hi,
I am currently testing many sort algorithms to improve the Marlin renderer
(AA 2D shape rasterizer), I integrated since OpenJDK9 and am still
improving for OpenJDK12 .
I created my MergeSort (top down, check for sorted parts, array / buffer
swap to minimize moves, isort on small sub arrays)
John,
Any feedback ?
We could discuss that during next OpenJDK workshop, but I would prefer
going slowly but surely.
Laurent
Le jeu. 29 nov. 2018 à 17:52, Laurent Bourgès a
écrit :
> Hi John & Brian,
>
> Thanks for the proposed approach, I agree we are in the design discuss
Hi John & Brian,
Thanks for the proposed approach, I agree we are in the design discussion;
adding such API enhancements will take time, I said 13 to not hurry for 12
(CSR...).
John, you wrote me a very detailed letter, I will try to be more concise
and focus on Array.sort() API.
Le jeu. 29
Hi,
I am happy to announce that I succeeded in writing my own BentleyBasher
working like a swiss clock:
- auto-tune benchmark passes & hot loop to obtain high accuracy on
measurements ~ 2% (guaranteed), with proper variance estimators
- test > 10 sorters with small, large & very large int[]
e predictable and much less depend on input
> data than in DPQS), but I strongly believe that concentrating efforts
> on testing corner cases performance and integrating RadixSort into JDK
> would yield much better performance than DPQS, at least for int[]
> arrays. Also the implementation is mu
?
Do you have a JMH test suite dedicated to array sorting ?
Cheers,
Laurent
Le mer. 14 nov. 2018 à 09:01, Laurent Bourgès a
écrit :
> Hi,
>
> I am a scientist and the author of the Marlin renderer, integrated in
> OpenJDK.
>
> In this renderer, I needed a fast sort algorithm on s
Hi Doug,
That's a pleasure to read you.
Le mar. 20 nov. 2018 à 13:17, Doug Lea a écrit :
> On 11/20/18 2:50 AM, Laurent Bourgès wrote:
> > Hi,
> > Any feedback on improving Java Sort API ?
>
> I think most considerations await progress on value types. I posted some
>
Hi John & Brian,
Thank you for your feedback finally, we almost agree Java Sort API could be
improved, in jdk13 possibly.
>
> Doug is right that there is an enormous potential list of sort methods,
> and we can't include them all. But I do miss the ability to extract
> indexes instead of
Hi,
I asked alan to update the webrev, but I can publish it myself...
Will do it asap,
Stay tuned,
Laurent
Le mar. 9 juil. 2019 à 22:19, Brent Christian
a écrit :
> Hi,
>
> Is the webrev incomplete? It only contains the changes for
> DualPivotQuicksort.java, and not for Arrays.java, etc.
>
>
on't know
> if
> > that would be less work than just comparing raw files.
> >
> > Alternatively, if it would be easiest for those familiar with the
> > evolution of this fix to leave things where Vladimir had them, I can
> do
> > that.
> >
Hi Brent,
Le jeu. 1 août 2019 à 02:32, Brent Christian a
écrit :
> Thanks, Laurent. I can sponsor this fix, get a RFR thread going for
> JDK-8226297, keep webrevs updated as the review progresses, etc.
>
Excellent, I will let you and Vladimir work on this review.
FYI I have implemented DPQS
Hi Brent,
Thank you for sponsoring this patch.
I tried to compare your webrev against my latest (diff patch files) but it
gives me too many changes lines.
Do you have another idea to see incremental changes only ?
(anyway I can compare raw files)
Thanks,
Laurent
Le lun. 5 août 2019 à 23:43,
,
Laurent
Le ven. 12 juil. 2019 à 09:34, Laurent Bourgès
a écrit :
> Hi,
> I asked alan to update the webrev, but I can publish it myself...
>
> Will do it asap,
> Stay tuned,
> Laurent
>
> Le mar. 9 juil. 2019 à 22:19, Brent Christian
> a écrit :
>
>> Hi,
>
shold for parallelism argument (0 -> 1)
2. Added constant for common parallelism
3. Updated byte / char / short counting sort.
"
Incremental patch change:
http://cr.openjdk.java.net/~lbourges/dpqs/dpqs-8226297/diff_dpqs_1_vs_0.log
Cheers,
Laurent
Le mer. 17 juil. 2019 à 17:12, Laurent Bou
Hi Vladimir,
First Thank you for these impressive results: 15% to 70% overall gains is
amazing and will make a big difference, Congratulations !
Could you publish the different test environment ?
- HW: cpu (lscpu output)
- OS version
- JDK version + JVM settings
Ideally you or I could write a
Thank you Volker for sharing your results.
It is amazing, to improve such widely used feature (zip -> jar, http
compression...)
Congratulations.
Laurent
Le jeu. 23 avr. 2020 à 12:19, Volker Simonis a
écrit :
> On Thu, Apr 23, 2020 at 10:56 AM Laurent Bourgès
> wrote:
> >
Hi Volker,
Could you give some benchmark results in the jbs bug to have an idea of the
performance gain ?
Thanks,
Laurent
Le jeu. 23 avr. 2020 à 10:20, Langer, Christoph
a écrit :
> Hi Volker,
>
> since it's not yet pushed, I also went over the change and I like it. +1
>
> One little style
(edges, rle tile cache).
Cheers,
Laurent
Le dim. 18 avr. 2021 à 09:11, Alan Bateman a
écrit :
>
> On 17/04/2021 19:02, Laurent Bourgès wrote:
> > Hi,
> > In the Marlin renderer & in other Unsafe use cases (pixel tile
> processing)
> > for java2d pipelines, I do use put
Hi,
In the Marlin renderer & in other Unsafe use cases (pixel tile processing)
for java2d pipelines, I do use putInt()/putLong() primitives even if the
address is not aligned (to 4 or 8 bytes) to get faster processing of byte
buffer or arrays...
Is it possible in java (jdk internals) to query cpu
1 - 100 of 121 matches
Mail list logo
