Mike Marchywka wrote:
----------------------------------------
Date: Sun, 21 Feb 2010 15:55:24 +0100
From: [email protected]
To: [email protected]
Subject: Re: [webkit-dev] are there any known or suspected memory issues with
webkit?
On 2010-02-21 at 13:14:59 [+0100], Mike Marchywka wrote:
The reason I ask is because I thought there were some concerns about leaks
( probably just stuff I saw skimming various google hits ) and I have
seen firefox and iceweasel light up my disk on very simple things ( like
typing stuff into forms). As I started looking through the code,
one of the first things I saw was something that looked like a hash table
of previously used pages- are there static "junk bins" of strong references
and stuff like that that could create memory leaks as they accumulate stuff
and never get cleaned or pruned?
The other thing is that IMO ( opposing views welcome) memory
access patterns are often an unappreciated issue on many
architectures. The reason I reacted to the threading question as
I did is that it seems, again in my opinion on superficial/ anecdotal
analysis, that this approach often seems attractive but contains
a number of issues, among them those related to memory or
other resource allocations, that reduce the effectiveness even
with an ideal multi-CPU system I did make this point
before with reference to one speed-versus-threads graph
from IEEE,
http://lists.boost.org/boost-users/2008/11/42263.php
Ceratinly " your mileage may vary" but resource
allocation and contention is probably already a big
deal and it may be a better place to look for
optimization. Launching a thread is a general idea
that can be used anywhere but digging into code may be
more effort and more specialized to a given task however.
Thoughts?
I don't understand the multi-threading nay-saying. Just as an L2 cache is a
technology to speed up memory access, multi-core
architecture is a way to increase processing speed of the CPU. Last time I
looked, a -j2 build of WebKit runs almost twice as fast as a
single job build on my Core2Duo system. So the technology obviously works. Just
because improving cache locality is a way to improve
the execution speed of a piece of software, it doesn't mean one should try to
prevent efforts to make software explore the increased
processing performance of additional CPU cores. And designing the software to
make proper use of multi-threading and scale well is
definitely not easy, or the cheap way out. Not at all.
Oh, it is not an attempt to discourage just not take something you happen
to have a lot of and put each one into a new thread esp when my
personal experiences seem to be related to memory depletion. The multi-core of
course
does benefit from multiple threads, but it helps if they are doing things
that can play well with each other and not step over each other.
The OP on the related topic indiciated he hadn't looked much at details,
I'm just suggesting looking first. And, of course, once your disk light comes
on for VM things do get quite slow. Indeed, maybe the threading model could
remove
some types of redundancy or thrashing but it won't do that if you just make a
lot
of copies of things that all become slower.
In my experience parallelizing browser algorithms on various hardware
configs, much of the benefit of exploiting new architectures is often
just getting more cache. Even if you're not CPU bound, as new multicore
hardware may work funny at the L1/L2 level, redesigning algorithms to
work better at this level not only improves sequential performance but
also essentially multiplies how much local cache you have.
There don't seem to be any technical questions on this thread, so I'll
stop proselytizing ;-)
[Obviously why browsers go way beyond L2/L3 is a concern as is the
prefetching technology, but those are somewhat orthogonal concerns to
speeding up the CPU or arguably bandwidth bound bottlenecks like painting.]
I guess from what I've seen personally on my machines the biggest problem
with browsing is VM and there are probably other issues with caching well
before you
get there. I always expected browsing to be IO limited but clearly there are
other limitations.
Best regards,
-Stephan
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_________________________________________________________________
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/201469228/direct/01/
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
