On Sat, Oct 9, 2010 at 3:45 PM, Dirk Pranke <[email protected]> wrote:
> On Fri, Oct 8, 2010 at 11:09 PM, Paul D. Fernhout > <[email protected]> wrote: > > Yes, there are similarities, you are right. I'm not familiar in detail > > because I have not used Chrome or looked at the code, but to my > > understanding Chrome does each tab as a separate process. And typically > (not > > being an expert on Chrome) that process would run a rendering engine (or > > maybe not?), JavaScript (presumably?), and/or whatever downloaded plugins > > are relevant to that page (certainly?). > > > > Yes, each tab is roughly a separate process (real algorithm is more > complicated, as the wikipedia article says). rendering and JS are in > the same process, but plugins run in separate sandboxed processes. > > C++ is a significant security concern; and it is reasonable to want a > browser written in a memory-safe language. > > Unfortunately, web browsers are large, extremely > performance-sensitive, legacy applications. All of the major browsers > are written in some combination of C, C++, and Objective-C (and > undoubtedly assembly in isolated areas like the JITs), and it's > unclear if one can reasonably hope to see a web browser written from > scratch in a new language to ever hope to render the majority of the > current web correctly; the effort may simply be too large. I was not > aware of Lobo; it looks interesting but currently idle, and is a fine > example of this problem. > > I continue to hope, but I may be unreasonable :) > > > Most major browsers are doing a much better job making sure they understand performance, how to evaluate it and how to improve it. C, C++, Objective-C, it doesn't matter. The key is really domain-specific knowledge and knowing what to tune for. You need a huge benchmark suite to understand what users are actually doing. Big advances in browsers are being had thanks to research into parallelizing browser rendering. But there are a host of other bottlenecks, as Microsoft's IE team pointed out. Ultimately when you are tuning at this scale everything looks like a compiler design issue, not a C, C++, Objective-C issue. These all just become high level assembly languages. A garbage JavaScript engine in C is no good. A fast JavaScript engine in C written with extensive performance tuning and benchmarks to ensure no performance regressions is good. Silverlight (managed runtime) blows away pretty much even hand-tuned JavaScript apps like the ones Google writes, by the way... unfortunately it uses no hardware accelerated rendering that I'm aware of. Current browser vendors have version branches w/ hardware accelerated rendering that parallelizes perfectly. Silverlight has its own problems, of course.
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
