On 09/24/2014 11:40 PM, Ulf Zibis wrote:
Am 24.09.2014 um 22:25 schrieb Peter Levart:
Hi,
String.hashCode() caches the result, so repeatable call to same
String instance is faster for 2nd and further invocations. But the
computation of hash code itself could be accelerated for a factor of
2 or more on todays CPUs. How? By parallelizing it. And I don't mean
computing it in multiple threads.
Here is a surprising result of a simple benchmark which computes hash
code of a 128 character string in 6 different ways:
Benchmark Mode Samples Score Score
error Units
j.t.HashBench.hashCode thrpt 8 8420103.795
162447.069 ops/s
j.t.HashBench.hashCode0 thrpt 8 8439058.660 2842.755
ops/s
j.t.HashBench.hashCode1 thrpt 8 13809510.573
337888.132 ops/s
j.t.HashBench.hashCode2 thrpt 8 15543687.568
716152.160 ops/s
j.t.HashBench.hashCode3 thrpt 8 18173224.431 49410.256
ops/s
j.t.HashBench.hashCode3x thrpt 8 8543020.232 18158.686
ops/s
Source:
http://cr.openjdk.java.net/~plevart/misc/StringHash/HashBench.java
This is really great!
Couldn't this be a tweak via HotSpot, instead uglifying and bloating
the Java and hence the byte code?
This is for HotSpot compiler guys to answer. Theoretically I think it is
possible. But it would have to be tailored to the very specific use case
and I don't know if such specific transformation would have wide-enough
applicability. If it would only speed-up String.hashCode and very
similar loops, it is less trouble to do that by hand in one or few
places...
Regards, Peter
-Ulf
