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 <[EMAIL PROTECTED]> wrote: > Hi, Sian! > > On Fri, Jul 18, 2008 at 1:16 PM, Sian January > <[EMAIL PROTECTED]> 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. >
