On Sun, Feb 10, 2013 at 9:44 AM, L. David Baron wrote:
> For some languages (e.g., HTML, and possibly also CSS) parsing could
> be relatively parallizable by splitting up the input into chunks and
> parsing each chunk by speculating on a likely state at the start of
> the chunk, having slight over
On Saturday 2013-02-09 12:34 +0100, David Bruant wrote:
> Le 08/02/2013 18:41, Simon Sapin a écrit :
> >For context, see other threads about my new CSS parser.
> >
> >Servo is made to "parallel all the things", right?
> Some algorithms are very hard to parallelize. Parsers would be a
> very good ex
Le 08/02/2013 18:41, Simon Sapin a écrit :
Hi dev-servo,
For context, see other threads about my new CSS parser.
Servo is made to "parallel all the things", right?
Some algorithms are very hard to parallelize. Parsers would be a very
good example, because they often look like "read a bit, chan
On Feb 8, 2013, at 09:41 , Simon Sapin wrote:
> What is the desired level of parallelism?
>
Hopefully whatever is fastest. :-)
Is it possible to keep these parts modular, and then perform experiments with
single task vs. multiple? It would be awesome if the strategy w.r.t. task
decompositio
Hi dev-servo,
For context, see other threads about my new CSS parser.
Servo is made to "parallel all the things", right? In a CSS parser, the
tokenizer and maybe the decoder (from bytes to Unicode) could each be in
their own task, running in parallel with the parser. Then each rule or
declara
5 matches
Mail list logo