On Sat, Oct 9, 2010 at 9:21 PM, John Zabroski <[email protected]> wrote: > > > 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.
True. There is a video floating around [1] with Lars Bak (team lead for the V8 engine) talking to Erik Meijer about how JavaScript VMs compare to the JVM and the CLR and how the latter two will always be significantly faster due to the differences in language designs and the optimizations they enable. But there's always NativeClient (as someone else linked to) if you need raw speed :) -- Dirk [1] http://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-Erik-Meijer-and-Lars-Bak-Inside-V8-A-Javascript-Virtual-Machine _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
