RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32
David Chase
david.r.chase at oracle.com
Mon May 20 17:24:10 UTC 2013
PS, the code generated by Visual Studio 2012 from the C version of the source is nowhere near
as good as what comes from gcc 2.6 or clang. Getting good code would require hand conversion
of 80 lines of assembler to the microsoft dialect, never mind the calling conventions.
That suggests disabling this optimization for Windows.
David
On 2013-05-20, at 1:14 PM, David Chase <david.r.chase at oracle.com> wrote:
>
> On 2013-05-20, at 11:28 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> On 5/20/13 6:49 AM, David Chase wrote:
>>> Suppose I split this bug (i.e., file a new bug) into the Intel-acceleration part and the fork-join part.
>>
>> Yes, please, do that.
>
> And, before I waste more time tearing my hair out, suppose that I punt on accelerating Windows until we are using a more modern Visual Studio?
> Because I went a looked at the problem, the assembly language has a completely different syntax, it would double the amount of ugly asm in that file, and the people with the performance problem were not running Windows.
>
>> You still don't want to do it in VM as intrinsic/stubs? ;)
>
> I think that would be a lovely idea.
> Can we get 16-byte alignment guaranteed from the GCC, and use of 128-bit wide xmm registers compiled in?
>
>> You would not have all these C++ issues and I can help you with that.
>
> It is clear that the compiler internals are the land of don't-ask-don't-tell.
> Perhaps we could slip a little fork-join parallelism in there, too? :-)
>
> David
>
More information about the core-libs-dev
mailing list