So, like all the other old gits
So, like all the other old gits
So you've probably all seen the 80 core CPUs in 5 years story.
One thing that I immediately thought (after, OMG WTF!) was "what the hell is the UI going to be like for that". For instance top currently has a summary line for each core, but having over 3 terminal screens (80x24 is as god intended) just for the summary seems unlikely to be appreciated. On the other hand having a program with a single task have CPU usage with an upper bound of 1.25% CPU seems less than useful. This seems really bad (Ie. can't treat that many cores seperately and you can't treat them as a single unit).
There's also the (probably huge) set of minor problems with things like And-httpd starting sysconf(_NPROCESSORS_ONLN) number of tasks by default. Which works well for the 1-4 CPU/core case, but is likely to be annoying with 80 cores.
So, I'm not sure if this is all tomhudsons fault
Exibit A, so we're going to do a "DB benchmark" to see how well the different OSes compare to each other. Ok, I can buy that
However, when running a "real world" test on different OSes it seems like crack to install an upstream MySQL tarball
And then to give a "methodology" that says:
I installed each operating system "stock" -- with default options -- and recompiled a kernel here and there when necessary, to add, for instance, SMP support in FreeBSD or increase memory allocation limits. For the most part, I didn't do any special OS tweaking beyond what was specifically recommended for MySQL. Any changes to the OS I made are documented in their respective sections below.
Oh, a recompile "here and there" and some random MySQL tweaking that doesn't appear to be documented and for the "non-special OS tweaking in Linux":
I ended up going with Gentoo 2004.3
... With Gentoo it was also relatively easy to install NPTL for 2.6 ... (although they [ed: NPTL] didn't make any difference) ... For these tests, I chose ReiserFS version 3.
hahahahahahahahahahahahahahahahahahahaha. Ahhh, I have to laugh or I'll cry.
I'm pretty sure it's the most tested open source code, so one the one hand it's hard not to brag
Still I'm running the example httpd on my ADSL, and I'm pretty sure it's secure
Is it me, or does noone actually read the web. One giant hypertext inverted WORM device.
Maybe, I'm getting cynical in my old age
But hey, I guess Fox is allowed to say it's a "NEWS" channel
So, as some of you may know, I'm pretty interested in scalable network IO. So I was pretty excited about the recent
Apart from the fact it mainly talked about dealing with network IO events, it completely screwed up the definition of the poll() API
It only touched on iovec's and scatter gather IO from the application POV, which is probably due to zero support for that from the DJB designed buffer_* string IO APIs. Also the connect() calls were all blocking, and I think the data traveled using httpbench never used more than a single socket at once (Ie. there weren't ever multiple sockets seeing data at once). Sigh, I guess I'll have to finish my text for all that stuff
On the other hand, there were a couple of interesting points I didn't know...
1.79 x 10^12 furlongs per fortnight -- it's not just a good idea, it's the law!