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...
- epoll now does Level triggered events by default (stupid, stupid, stupid...). People should just learn to deal with edge triggering properly (of course I'm slightly biased as Vstr helps out a lot here).
- DJB has an IO API
- DJB wants to do non-blocking IO, I'd assumed DJB was firmly in the fork() and blocking IO model after qmail.
- Felix has written a read only LDAP server
- The description of the O(1) schedular was pretty good.
- The description of level triggering events and edge trigger events, was also pretty good.
- It's probably always good to have advice out there telling people not to use threads, even if I'm not sure the numbers are right.
- It is nice to have a simple reference for all the IO event mechanisms, this would be better somewhere on c10k really though, IMO. esp. as it's more likely to be accurate.
- I didn't realise you could make BSD TCP_NOPUSH actually do anything useful, although TCP_CORK is vastly nicer it appears you might be able to get generic code to use TCP_NOPUSH on *BSD with most of the gain.