harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev" <aleksey.shipi...@gmail.com>
Subject Re: [classlib][pack200] Decoupling I/O and processing for unpacking scenario
Date Fri, 18 Jul 2008 10:35:50 GMT
BTW, here's the prototype that uses such the decoupling [2]. It gives
+50% boost on 8-core Xeon for unpacking scenario, which is near to
previous estimations.

Thanks,
Aleksey.

[2] https://issues.apache.org/jira/browse/HARMONY-5918

On Fri, Jul 18, 2008 at 1:33 PM, Aleksey Shipilev
<aleksey.shipilev@gmail.com> wrote:
> Hi, Sian!
>
> On Fri, Jul 18, 2008 at 1:16 PM, Sian January
> <sianjanuary@googlemail.com> wrote:
>> I think there needs to be some processing on the read stage, because the
>> length of some bands depends on the contents of previous bands so you won't
>> know how much to read unless you do some processing.  But some things can be
>> done afterwards like sorting the constant pool, so there's definitely an
>> opportunity for parallelism there.
> Yes, a huge part of the non-dependent-from-I/O operations are already
> extracted in unpackProcess(). Of course, a part of computation should
> reside in read because of unknown bands' size, but if we manage to
> extract some more not related to reading computations from reading
> stage, it would worth a lot (see previous calculations).
>
> Actually I see this is a gap in pack200 spec. I would really like to
> have the segment size in segment header to read the entire segment at
> once, but... *sigh*.
>
> There is a bunch of people interested in playing with parallelism in
> pack200: Andrew wanted to have some, I would enjoy seeing the parallel
> decompressor, Sergey Salishev wanted to hack around too :) So we need
> to discuss whether my approach to parallelism is ok, does someone
> object, or whatever else.
>
> Thanks,
> Aleksey.
>

Mime
View raw message