avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Romanoff (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AVRO-1282) Make use of the sun.misc.Unsafe class during serialization if a JDK supports it
Date Wed, 24 Apr 2013 02:07:16 GMT

    [ https://issues.apache.org/jira/browse/AVRO-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13639987#comment-13639987

Leo Romanoff commented on AVRO-1282:

>How much do those improvements help the Generic tests? I assume they are still dominated
>the issues with the decoder. Although decreasing the time of a Float read by 35% is a
big win, 
>it is a small part of what happens with Generic/Specific/Reflect reading. Does using unsafe

>here break anything if the system's byte order does not match?

Well, if you mean the last numbers I posted, they were because of using Unsafe for IO. I.e.
it should provide the same kind of speedups to any of Generic/Specific/Reflect as it simply
provides a faster stream implementation.

> Your results for reading Floats/Doubles above are slower than mine, is this because you
> now populating an array when reading as well? 

Yes. There are a few reasons for populating the array when reading:

1) Make it more symmetric to writing, as writing in FloatTest/DoubleTest always iterates over
an array. And it means additional memory accesses, which also have their cost.

2) It is more realistic scenario, as most deserializers would store results somewhere. And
as I just mentioned, storing comes at cost of memory access. And those memory accesses seem
to have a very big impact on the performance.

3) For scehma-based serialization performance tests like Reflect-based, it is almost impossible
to decouple pure reading from storing the result somewhere. Therefore it is unfair (or useless)
to compare them with vanilla FloatTest/DoubleTest reading speeds as they measure different
things. With my little change to reading it seems to make more sense.

> The benchmark was intended to isolate (as best as possible) the read and write portions
> the decoder/encoder? I'd be interested in looking at this code.

The code change is trivial. It is in the readInternal. It basically allocates an array before
a loop and then inside a loop it assigns each read object to a corresponding array element,
thus filling the array with a content.

> As for arrays of primitives, we should look into Group varint encoding and similar 
> techniques: ...

Yes, I've seen this paper before. IMHO, it is faster than the usual varint encoding, but it
will be slower (though more space efficient) than what Unsafe-based primitive arrays serialization
does. And the reason for this is the number of memory accesses and branching. Unsafe-based
array serialization just copies bytes and it does it in chunks of 4 or 8 bytes per instruction.
No branching at all. You can hardly beat it, I'd say. 
(As a remark, I've experimented with Kryo and have seen that Kryo using Unsafe-based IO +
LZ-like compression on top of it is often faster than Kryo using varing encoding for the same
content while producing a compressed output of comparable size)

> In general, lets separate out the Unsafe enhancements for Reflection from those that
> for the Input/Output streams. Lets get the reflection work in this ticket done and 
> committed, then move on to other enhancements.

I agree. We should not mix to many things in this ticket.

> A third related to other non-Unsafe performance improvements, for example those you allude

> to with:
> Coming back to your message about reading doubles and floats and observation that they
> much slower with ReflectDatumReader/Writer. I just did some profiling and found some

> issues. With small changes, I could significantly improve write performance and improved
> bit read performance. All this without Unsafe reads/writes into streams yet.

This one is still in scope of this ticket, IMHO. It affects only ReflectDatumReader/Writer
and the changes are mostly in my ArrayAccessor class. I'll provide an updated patch today.

BTW, should I include TestFloat's/TestDouble's readInternal changes mentioned above into this
patch or should I leave them out?

> Make use of the sun.misc.Unsafe class during serialization if a JDK supports it
> -------------------------------------------------------------------------------
>                 Key: AVRO-1282
>                 URL: https://issues.apache.org/jira/browse/AVRO-1282
>             Project: Avro
>          Issue Type: Improvement
>          Components: java
>    Affects Versions: 1.7.4
>            Reporter: Leo Romanoff
>            Priority: Minor
>         Attachments: avro-1282-v1.patch, avro-1282-v2.patch, avro-1282-v3.patch, avro-1282-v4.patch,
avro-1282-v5.patch, avro-1282-v6.patch
> Unsafe can be used to significantly speed up serialization process, if a JDK implementation
supports java.misc.Unsafe properly. Most JDKs running on PCs support it. Some platforms like
Android lack a proper support for Unsafe yet.
> There are two possibilities to use Unsafe for serialization:
> 1) Very quick access to the fields of objects. It is way faster than with the reflection-based
approach using Field.get/set
> 2) Input and Output streams can be using Unsafe to perform very quick input/output.
> 3) More over, Unsafe makes it possible to serialize to/deserialize from off-heap memory
directly and very quickly, without any intermediate buffers allocated on heap. There is virtually
no overhead compared to the usual byte arrays.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message