How the JVM compares strings on x86 using pcmpestri
1–10 of 73 posts
Re: How the JVM compares strings on x86 using pcmpestri
#2This guy's blog is awesome. A lot of in-depth information, original research, nice and funny writing style. I hope he finds some time to write / speak more soon.
Re: How the JVM compares strings on x86 using pcmpestri
#3UTF-16 is one of these ill-fated developments that curse some languages & platforms (WinNT incl Win10, WinAPI32, Java, Flash, JS, Python 3) to his day.
compareTo uses 0x19, which means doing the “equal each”
(aka string comparison) operation across 8 unsigned words
(thanks UTF-16!) with a negated result. This monster of an
instruction takes in 4 registers of input:Re: How the JVM compares strings on x86 using pcmpestri
#4It's great to see the disassembly. Would be curious to see the assembly performance-tested against other similar implementations (UTF-16 compatible.)
Btw, frik, you are shadow banned. I sense it is for the frigid opinions. Personally, I see them as "ok" as long as you provide technical reasons for your opinions and are polite enough.
Re: How the JVM compares strings on x86 using pcmpestri
#5Click here to discover that crazy instruction! C++ programmers HATE IT!!
(I am just ironizing about the title, the content is actually great!)
Re: How the JVM compares strings on x86 using pcmpestri
#6> But did you know there is also a secret second implementation? String.compareTo is one of a few methods that is important enough to also get a special hand-rolled assembly version.
oooooh.
Is there a list somewhere of all the functions that have had such special treatment?
Re: How the JVM compares strings on x86 using pcmpestri
#7It's great to see the disassembly. Would be curious to see the assembly performance-tested against other similar implementations (UTF-16 compatible.) Btw, frik, you are shadow banned. I sense it is for the frigid opinions. Personally, I see them as "ok" as long as you provide technical reasons for your opinions and are polite enough.
I figured out the 2nd part of this comment is talking about https://news.ycombinator.com/item?id=16090274.
I can see this post fine; it's not "dead".
If you ever browse /newest and/or have showdead on you've probably seen the occasional genuine spam that turns up on here. I think the HN admins have a genuinely hard time with the current volume.
To deal with the current state of affairs Arc apparently has to be exceptionally aggressive, and I've seen it generates a very small stream of false negatives.
In future, open the post (click the timestamp) and click "vouch". If it stays [dead], hopefully enough other people also vouch for it.
Re: How the JVM compares strings on x86 using pcmpestri
#8> But did you know there is also a secret second implementation? String.compareTo is one of a few methods that is important enough to also get a special hand-rolled assembly version. oooooh. Is there a list somewhere of all the functions that have had such special treatment?
The feature is called "intrinsics", this claims to be a list: https://gist.github.com/apangin/7a9b7062a4bd0cd41fcc
Re: How the JVM compares strings on x86 using pcmpestri
#9> But did you know there is also a secret second implementation? String.compareTo is one of a few methods that is important enough to also get a special hand-rolled assembly version. oooooh. Is there a list somewhere of all the functions that have had such special treatment?
The intrinsics for the HotSpot JVM are declared here: http://hg.openjdk.java.net/jdk10/jdk10/hotspot/file/5ab7a67b...
(look for "java_lang_Math" for instance)
Re: How the JVM compares strings on x86 using pcmpestri
#10UTF-16 is one of these ill-fated developments that curse some languages & platforms (WinNT incl Win10, WinAPI32, Java, Flash, JS, Python 3) to his day. compareTo uses 0x19, which means doing the “equal each” (aka string comparison) operation across 8 unsigned words (thanks UTF-16!) with a negated result. This monster of an instruction takes in 4 registers of input:
Java uses UTF8 in latest release for strings without special characters.
http://www.baeldung.com/java-9-compact-string
UTF16 is not really a curse for languages that require it. String operations in non-English languages are very fast because of it, and most software these days has to deal with localization.