View mode: basic / threaded / horizontal-split · Log in · Help
September 04, 2008
Re: Google Chrome and process-based design
davidl wrote:
> 在 Wed, 03 Sep 2008 22:08:27 +0800,Alexander Panek 
> <alexander.panek@brainsware.org> 写道:
> 
>> Denis Koroskin wrote:
>>> You already know that Google is making a buzz with their new Chrome 
>>> browser.
>>> Go download and test it if you didn't do yet (www.google.com/chrome/, 
>>> Windows only for now).
>>>  It is heavily multi-threaded and uses separate process for each 
>>> window, each tab, each plugin etc. When one tab hags or a plugin 
>>> crashes, nothing bad happens. The browser continues working as if 
>>> nothing changes. It even has a built-in process manager, try opening 
>>> youtube.com and killing a flash player plugin.
>>>  You can read the whole story at www.google.com/googlebooks/chrome/
>>>  This is an example of process-based designs implementation which is 
>>> what D2 aims at, and it is clearly a success.
>>
>> It's funny, just a week ago or so Bartosz Milewski published a blog 
>> entry about how processes scale better than threads..
>>
>> I tried Chrome and I'm really impressed by how responsive it is. Also, 
>> the UI is kept very minimalistic, yet it doesn't lack any features. 
>> The website-application feature is also a very handy thing.
>>
>> Overall, I'd say Google Chrome is quite an impressive product. Would 
>> love having a D port. :P
> 
> Who will ever want to port a such big project? 437MB Source tarball(WTF, 
> a browser bigger than OS source base)

I suppose you noticed the emoticon (":P") at the end of that sentence.


> Google goes the wrong way. It just extends the current web crap not 
> reinvent something smarter.

Wrong or right, it doesn't extend anything. Google just happened to 
release a new, blazingly fast browser. I don't know in what way this can 
be attributed as "web crap" or similar. Do you have any better idea?
September 04, 2008
Re: Google Chrome and process-based design
Alexander Panek wrote:
> davidl wrote:
>> 在 Wed, 03 Sep 2008 22:08:27 +0800,Alexander Panek
>> <alexander.panek@brainsware.org> 写道:
>>> Overall, I'd say Google Chrome is quite an impressive product. Would
>>> love having a D port. :P
>>
>> Who will ever want to port a such big project? 437MB Source
>> tarball(WTF, a browser bigger than OS source base)
> 
> I suppose you noticed the emoticon (":P") at the end of that sentence.

437MB?  I gotta go check that out (as in verify, not load my poor disk
with even more stuff).

>> Google goes the wrong way. It just extends the current web crap not
>> reinvent something smarter.
> 
> Wrong or right, it doesn't extend anything. Google just happened to
> release a new, blazingly fast browser. I don't know in what way this can
> be attributed as "web crap" or similar. Do you have any better idea?

It's great for Google!  Now Mozilla can use the lessons learned from
Chrome to make Firefox better!  Chrome is Google saying "we want a
better browser.  So we made a proof of concept for you to both copy and
improve upon."  I don't think Google is fixated upon webkit at all.
They just wanted something quick and easy that they could pop into
Chrome, which is mainly about the simplified interface, more survivable
process-based design, and the much-faster JavaScript engine.

Because Chrome is Open-Source, I see no reason why the Mozilla team and
the Chrome team cannot benefit from a little synergy as they learn from
each other to build better browsers.  True, it's competition, but it's
/Open-Source/ competition, the kind where everyone wins.
September 04, 2008
Re: Google Chrome and process-based design
Chris R. Miller wrote:
> Alexander Panek wrote:
>> davidl wrote:
>>> 在 Wed, 03 Sep 2008 22:08:27 +0800,Alexander Panek
>>> <alexander.panek@brainsware.org> 写道:
>>>> Overall, I'd say Google Chrome is quite an impressive product. Would
>>>> love having a D port. :P
>>> Who will ever want to port a such big project? 437MB Source
>>> tarball(WTF, a browser bigger than OS source base)
>> I suppose you noticed the emoticon (":P") at the end of that sentence.
> 
> 437MB?  I gotta go check that out (as in verify, not load my poor disk
> with even more stuff).

I ran, I checked, I became intrigued, so I downloaded and decompressed.

Firstly, it's 1.682 GB of raw sources.

Secondly, I ran an HDGraph scan of the tree to see where everything is.

199.16 MB of hunspell dictionaries
147.46 MB of Chrome test data
228.31 MB of Chrome tools test data marked as a "reference build"
147.87 MB of webkit layout test results data
= 722.8 MB of non-code data

Therefore 1.682 GB - 722.8 MB = 959.2 MB total of source code

The Chrome source itself, minus the data and tools data, etc. is only
57.75 MB of source code for the browser itself.  The rest is third party
libraries, such as Cygwin libraries and what looks to be the better part
of 77 MB of a Perl interpreter and attached libraries, 158 MB of "icu38"
library sources, etc.  It's really no wonder it's such a large download,
since all you need to build the browser is MSVC 2005 and the Windows
SDK.  Otherwise you don't need to go download any of the other things
yourself.  So on closer inspection is does seem like a more appropriate
level of data for a browser.

Looking at a few of the source files individually, it does appear that
much of the code is reasonable, and that most of the data is just tools
for unit tests, etc.

Just thought I'd share.
September 04, 2008
Re: Google Chrome and process-based design
Denis Koroskin wrote:

> You can read the whole story at www.google.com/googlebooks/chrome/

On page 16 they mention "precise GC".

-manfred

-- 
If life is going to exist in this Universe, then the one thing it 
cannot afford to have is a sense of proportion. (Douglas Adams)
September 04, 2008
Re: Google Chrome and process-based design
Manfred_Nowak wrote:
> Denis Koroskin wrote:
> 
>> You can read the whole story at www.google.com/googlebooks/chrome/
> 
> On page 16 they mention "precise GC".
> 
> -manfred
> 

Are you suggesting we should start talking about how this could be done in D ?

-Tomas
September 04, 2008
Re: Google Chrome and process-based design
"Denis Koroskin" wrote
> You can read the whole story at www.google.com/googlebooks/chrome/

Hey, this comic is really awesome for explaining things!  The author did a 
great job.  Any artists out there that can explain the D benefits this way? 
I think that might go a long way for newb's.

-Steve
September 04, 2008
Re: Google Chrome and process-based design
Steven Schveighoffer wrote:
> Hey, this comic is really awesome for explaining things!  The author did a 
> great job.  Any artists out there that can explain the D benefits this way? 
> I think that might go a long way for newb's.

That's certainly true! Though, they should've kept it a tad shorter. It 
was kind of getting boring at some point.
September 04, 2008
Re: Google Chrome and process-based design
On Thu, Sep 4, 2008 at 10:14 PM, Steven Schveighoffer
<schveiguy@yahoo.com> wrote:
> "Denis Koroskin" wrote
>> You can read the whole story at www.google.com/googlebooks/chrome/
>
> Hey, this comic is really awesome for explaining things!  The author did a
> great job.  Any artists out there that can explain the D benefits this way?
> I think that might go a long way for newb's.
>
> -Steve

I was reading that comic thinking man this guy *must* have really
studied those "understanding comics" books because he's using all the
techniques just like they're described in that book.

Turns out the comic was done by Scott McCloud, who *is* the
Understanding Comics books guy.

So looks like all we have to do is pay Scott McCloud large sums of
cash and he will make us a nice comic for D too!

--bb
September 05, 2008
Re: Google Chrome and process-based design
Tomas Lindquist Olsen wrote:
> Manfred_Nowak wrote:
>> Denis Koroskin wrote:
>>
>>> You can read the whole story at www.google.com/googlebooks/chrome/
>>
>> On page 16 they mention "precise GC".
>>
>> -manfred
>>
> 
> Are you suggesting we should start talking about how this could be done 
> in D ?
> 
> -Tomas

It would require compiler support.

It would require emitting pointer maps for each stack frame and each object.

It's relatively straightforward. If you align pointers on word 
boundaries, you only have to store one bit per word; else, one bit per 
byte; so this is not a terribly large overhead (no more than a couple 
bytes for a typical function, probably).

It wouldn't be terribly fast, but it probably wouldn't be an extreme 
slowdown either, most likely.
September 05, 2008
Re: Google Chrome and process-based design
Tomas Lindquist Olsen wrote:
> Manfred_Nowak wrote:
>> Denis Koroskin wrote:
>>
>>> You can read the whole story at www.google.com/googlebooks/chrome/
>>
>> On page 16 they mention "precise GC".
>>
>> -manfred
>>
> 
> Are you suggesting we should start talking about how this could be done 
> in D ?
> 
> -Tomas

A major benefit of a precise GC is that you can turn it into a moving 
GC. Without a precise GC, you might change some random sequences of 
bytes to something else because it looks like a pointer to something you 
moved; not so with a precise GC.
1 2 3
Top | Discussion index | About this forum | D home