Xooglers - Google Discussed by Ex-Googlers 211
perler writes to tell us that Xooglers, a relatively new website created so that ex-Google employees could reminisce and share, has been gaining a great deal of popularity recently. The website shares what went wrong, what went right, and all of the funny happenings in between. Quite an interesting piece of Google history.
Opening a Window to Google.... (Score:3, Informative)
http://www.intuitive.com/blog/google_fires_blogger _and_the_evils_of_gossip_and_innuendo.html [intuitive.com]
I'm not suprised there's now a Blog completely dedicated to ex-Google employees. It seems that they (Big G) don't take kindly to outsiders looking in... And God help you if you try to open the window and give others a peek.
Why they quit... (Score:5, Informative)
Re:Why "ex" googlers? (Score:3, Informative)
Re:Why "ex" googlers? (Score:5, Informative)
From the blog (Ron's first post [blogspot.com])
So that's why Ron left, I'm not sure if Doug's said why he left yet.
Re:Opening a Window to Google.... (Score:3, Informative)
Re:Scroll down (Score:1, Informative)
More info about the blog (Score:2, Informative)
you can find more information about here-
http://www.addict3d.org/index.php?page=viewarticl
Most retarded Slashdot comment ever? (Score:1, Informative)
Re:obvious question (Score:4, Informative)
From the blog (Ron's first post [blogspot.com] [blogspot.com])
So that's why Ron left, I'm pretty sure Doug hasn't said why he left yet. So no, Ron wasn't fired.
Re:If you read the stuff (Score:5, Informative)
I guess you missed this [blogspot.com]:
Ron sez... oh wait, don't need that any more.
OK, time to wrap up this little soap opera.
The problem turned out to be something called a race condition, which is one of the most pernicious and difficult kinds of bugs to find. (Those of you who are technically savvy can skip to the end.)
Most modern server code is multi-threaded, which means that it does more than one computation at once. This is important because computers do more than just compute. They also store and retrieve information from hard disks, which are much, much slower than the computers. Every time the computer has to access the disk things come to a screeching halt. To give you some idea, most modern computers run at clock speed measured in gigahertz, or billions of cycles per second. The fastest hard disks have seek times (that is, the time it takes the drive to move the read/write head into the proper position) of several milliseconds. So a computer can perform tens of millions of computations in the time it takes a hard disk just to get into position to read or write data.
In order to keep things from bogging down, when one computation has to access the disk, it suspends itself, and another computation takes over. This way, one computer sort of "pretends" that it is really multiple computers all running at the same time, even though in reality what is happening is that one computer is just time-slicing lots of simultaneous computations.
The ad server, the machine that actually served up ads in response to search terms, ran multi-threaded code written in C++, which is more or less the industry standard nowadays for high-performance applications. C++ is byzantine, one of the most complex programming languages ever invented. I've been studying C++ off and on for ten years and I'm still far from being an expert. Its designers didn't really set out to make it that complicated, it just sort of accreted more and more cruft over the years until it turned into this hulking behemoth.
C++ has a lot of features, but one feature that it lacks that Lisp and Java have is automatic memory management. Lisp and Java (and most other modern programming langauges) use a technique called garbage collection to automatically figure out when a piece of memory is no longer being used and put it back in the pool of available memory. In C++ you have to do this manually.
Memory management in multi-threaded applications is one of the biggest challenges C++ programmers face. It's a nightmare. All kinds of techniques and protocols have been developed to help make the task easier, but none of them work very well. At the very least they all require a certain discipline on the part of the programmer that is very difficult to maintain. And for complex pieces of code that are being worked on by more than one person it is very, very hard to get it right.
What happened, it turned out, was this: the ad server kept a count of all the ads that it served, which it periodically wrote out to the database. (For those of you wondering what database we were using, it was MySQL, which leads to another story, but that will have to wait for another post.) It also had a feature where, if it was shut down for any reason, it would write out the final served ads count before it actually quit. The ad counts were stored in a block of memory that was stack allocated by one thread. The final ad counts were written out by code running in a different thread. So when the ad server was shut down, the first thread would exit and free up the memory holding the ad counts, which would then be reused by some other process, which would write essentially random data there. In the meantime, the thread writing out the final ad counts would still be reading that memory.
Re:Did you actually read it? (Score:0, Informative)
Re:News? (Score:3, Informative)
An interesting source of information on Google has been created recently. So, it's new. It's newsworthy on
Re:News? (Score:1, Informative)