The system-boards/motherboards are $10,000 each, not $100,000, I believe. Still, a 2GByte memory module from Sun for the Starfire costs $10,000 to, if memory serves. The case alone (with no system-boards) costs $200,000 or something.
It's so absolutely laughable that Microsoft is trying to claim the high ground in availability/reliability over Sun.... This is from a company that to get '99.9%' reliablility you need 4 computers - the other 3 purely for backup, and this figure has so many cop-outs (ie doesn't count if it's planned - ie you're installing something and the OS decides you need to reboot, you need to change the hardware etc - or if it's a network problem, or a problem with any of the applications) in the contract, that it isn't hardly even worth the paper it's printed on.
A single Starfire is rated as being able to deliver 99.95% availability with one - ie no clusters, and without all those caveats above - though it does need to be setup with reliability in mind for this - there's plenty of options.... Starfires aren't simple either - up to 64 CPUs, many more PCI and similar slots, memory slots, etc, etc. So, plenty of things to go wrong. Similar sized computers (from everyone) are really hard to transport without something going wrong. The only people more nutso on reliability on 'big iron' computers are IBM (from the companies I know a fair bit about anyway). Not only do they have backup CPUs, in their CPUs they do the same operation twice (in parallel, with checking at the end) to trap the ultra-freak chance of cosmic radiation or something casuing a flipped bit, or worse. (yes, they do seriously actually worry about such things... I remember an IBM proposal about how to design memory that can handle a once-a-month chance, for when you have a huge about of RAM, for some particular kind of radiation....)
The only complaint I've ever heard about Starfires in general is that if a PCI card (though not SBus card) breaks down it can hang the entire system until an operator manually flicks a switch to say that that particular card is defunct. Though this is really because of how PCI works - Sun's 99.999% reliable Netra 1800 has some highly specialised custom hardware to get around this problem with PCI cards, as well as backup CPUs and plenty of other stuff... ridiculously expensive too, they are... though apparantly more cost effective than anything in the same class. The Netra 1800s are a few months old, while the Starfire design is over 2 years old, btw.
I dunno about all of MS's claims, but I'm pretty damn sure that you can have hardware redundancy for just about everything, if you want, including the Ultra-5 controller. Most of the other claims seem to be related to the fact that you can hot-swap PCI cards, memory, CPUs and even mother-boards in a Starfire...
EBay do seem to have had more than their fair share of problems though... quite a few hardware problems it seems - I vaguely remember a problem earlier in the year was due to some controller card or something. As far as I know, nobody has had anything close to the problems EBay are having with their Starfire(s)...
Another little point... MS's idea of expensive downtime is $10,000/hour. I remember reading something on Sun's site a while back about high end availability systems. Sun's idea of expensive downtime is $10,000,000/hour - ie stockbrokers. They also had a list of most common causes for 'unplanned' downtime on their HA systems - first was 'operator error' (or lack of training, etc). I can't remember was second was, but third was 'fire'! (I'm pretty sure Sun's computers don't have a reputation for spontaneous combustion!)
Whenever I see people discussing the "end of the PC", they seem to be getting misquoted a bit, or people are just latching onto the headline. What I mean is, that they're really predicting "the end of the era where a user's Personal Computer dominates where they do their work."
Putting it another way, a particular bit of hardware becomes less important, and instead the data and services become more important. So, say within a business, you can log onto any (or most, at least) computers around, and you get the same data, same functions, same customised desktop at each and every place. Or, instead of taking a laptop or handheld, you login remotely (at the hotel, airport, general kiosk, whatever) and access your stuff like that. Or you just borrow a handheld/laptop from anywhere, and providing it has the required client stuff, then it takes little effort to 'customise' it, because your particular settings and files are exportable.
An example of this sort of thing is Sun's recently released i-Planet software. All you need is a bit of hardware, with Java and internet access, and (without taking any software with you at all, just as password) you can remotely, and securely, get access to your mail, files, etc from it. (of course, you do need the required server stuff setup first.)
Windows is very badly suited to doing this sort of thing (in general, not just the i-Planet example), though Microsoft have been cludging in some hacks around this.
To workers/members of the public, it probably won't make that big a difference for a while, unless they do lots of 'remote' work. It will make a much bigger difference to the IT departments, and sys-admin though...
Cold Fusion research is being carried out in lots of countries, and they all have similar problems - getting funding and people to pay attention. Here in the UK, a friend of mine is doing research into fusion-like stuff - they're not trying for commercial applications, just researching into how the physics work. They're having trouble getting funding too, and it's not like they don't have a lot of respect from the rest of the scientific community.
However, in the university where they work, nobody would be able to do Cold Fusion research there, even if they paid for it themselves. There is such a bad stigma attached, that it would be just impossible.
Okay, maybe I should have done a bit more research about IPv6 for other unixs and OSs than checking Dejanews...
It seems all the unix guys have IPv6 implimentations of some kind. Novell are 'developing' one, and supposedly Windows 2000 will have it, though I'm not sure. Not sure what the status with Apple is either, though.
Besides, since some of your apps (everything that assumes IP address is 32 bit) will need re-writing to make use of it I don't think it's going to become a really important feature anytime soon...
As somebody points out above, Linux doesn't have dibs on 64bit kernal stuff - certainly just about every commercial unix bunch has this 64bit option. They don't seem to have researched the commercial Unixs much in general. Not that surprising in some ways - until recently most people were still predicting the death of Unix...
I dunno about IPv6 for the other unix guys, but there is a Sun provided IPv6 patch available for Solaris, and has been around since 1997 - for Solaris 2.5. Such a patch apparantly works on Solaris 7 too, though the web page doesn't say - it's bit outa date with regards to OS versions. Anybody know what the case is for Irix, and the other big boys? Besides, last I heard IPv6 hadn't even been completed yet, and I have no idea how long it'll be until it's being used significantly - ie I think bringing up IPv6 is a bit redundant when talking about current NOSs.
I wasn't particularly impressed by this article. Could have been better in a couple of ways (in some ways it seemed to have re-hashes from other articles going on about Netware VS Windows), and besides, we've seen so much similar articles it's getting boring... ^-^
PS Before someone asks, IPv6 is to replace IPv4 sometime and give us 128 bit IP addresses, instead of 32 bit. To put it simply.
As just about everyone has said, Sun's SCSL is not 'open source' (tm), nor does it try to be. XFS is not by Sun either, it's by SGI. Here is an linuxworld article about what liscence XFS will use - basically, the SGI guy wants to GPL it, if the lawyers will let him. (not bad, eh!) However they don't discuss other OSs - (I hope XFS won't be just for Linux). However, from what I've heard, XFS was designed assuming 64bit address space, so you might (initially) only be able to use it on Alpha, SPARC and MIPS versions of Linux. XFS uses file journaling and logging - read here for about this, from a SunWorld article about Solaris file-systems, which is pretty general.
btw, Sun's SCSL is aimed more at commercial developers (including Sun's OEMs) and researchers, not so much general members of the public. However, they are releasing quite a bit of stuff under the SCSL - Java, Jini, HotSpot (later this year), their SPARC processors and several other software products. They seems to be SCSL'ing their products in general. They haven't said much about SCSL'ing Solaris recently - the last time it was brought up they said it would be quite hard to do, because of all the liscences.
I suppose there will be inevitable comparisons between Beowulf and Sun's HPC software, and SMP kit. The main hardware difference is bandwidth and latency - Beowulf seems more about combining lots of single CPU (or low CPU count, eg 1-4) boxes in a network, possibly having several hundred of such boxes. Sun's approach to high end computing is to have big SMP boxes (a single Starfire E10000 can take 64 UltraSparcs) with the option of clustering a few of them - currently limited to 4, ie 256 processors. A Starfire has a 6Gbyte/s I/O bus and 15Gbyte/s main memory bus, which is rather better than Ethernet. Sun's approach is more expensive, but it also solves a wider class of problems well. For some things (eg cracking codes, rendering) you don't need much interprocess communication or bandwidth, so it scales well with Beowulf, but for other things (some kinds of database operations, eg OLAP, and data intensive scientific calculations) you really need very high bandwidth and very low latency (close to main memory speeds) which is where Beowulf doesn't do so well. Still, some things don't scale so well, even on a Starfire... Btw, the Starfire is over 2 years old.
Cue Sun's next gen super-computer, codename Serengheti, which has a completely different architecture. It's memory architecture is called Cache Only Memory Architecture (COMA), which seems to have been in development for a long long time at Sun. A single box will take 128 processors, and you'll be able to cluster 8 of them, for a total of 1024 processors. It'll be powered by Sun's UltraSparc-III, which recently reached first silicion, and has b ooted on Solaris. Incidentaly, the UltraSparc-III has hardware support for 1024 processors, and is supposed to be out in volume production by the end of the year. However, Serengheti won't be out until about the 2nd half of 2000.
I did specifically say that the object allocation was really fast. I mean 'Object boring = Object->new()' type thing. Ie 'malloc' in C. How trivial things like in your code example are allocated are kinda simple - it's static allocation. Dynamic allocation is a lot more interesting, and difficult. I'm not really sure of the details, but allocating an object on the stack (in C++) is the fastest method possible, really, though it has limitations - probably can't have any sized object, or huge numbers of objects, and object can probably only exist while you're in (or 'below') the current scope.
How Sun got their heap allocator to be as fast as C++'s stack allocator is pretty simple, more or less. (read their white papers and data sheets for more). Basically, you have a big 'stack' just for objects, and when you get to the end, you go back to the start, and for all the old (dead) objects there (often most of them) you just clear them out, and if an object is still live then you move it to a different block, where objects are expected to last longer, and has a more complicated algorithm to keep things tidy. Of course, if you're allocating huge numbers of objects that last a long long time, then Sun's method will slow down... though any method would (but if you know you're going to do this, you could make the heap bigger)
PS Your code example is just dead code, so a C compiler would just drop that code. HotSpot will also do this optimisation.
I'm too tired to write much (I love all-night coding sessions, honest). As some general points... 1) if you're going to use HotSpot, read all the docs. It's quite easy to write a simple 'benchmark' that goes really slow on HotSpot. (then change about 2-3 lines and it goes 20x faster)
2) Performance really does vary a lot. Best are predominantly Java server-apps - typical speed-up is 2-4 fold.
3) Client/graphics don't change up because most of the time running for them is in the binaries, not Java byte-code. According to Java's creator, the graphics guys are spending all their time making the code faster and leaner the moment...
4) JavaWorld HotSpot article - checkout the VolanoMark scalability on Solaris - WOAH! (half way down)
5) Apps with heavy object usage really do benifit. I've seen one example with a compiler with a C++ and Java version. The Java version with HotSpot was 50% faster than the C++!
6) Garbage collection and memory allocation is amazing - hardly notice garbage collection any more, and some people reckon the object allocation (on the 'heap') is as fast as C++'s on the stack! (in C++, allocating to the stack is much faster than the heap)
7) The HotSpot code was designed to be highly portable
8) HotSpot is free to use.
9) HotSpot will come out under Sun's "Community Source liscence" in about 6 months. (enough time to patent everything?)
Sun made Solaris 'free' for non-commercial use nearly a year ago. Page the freesolaris page. Because they still charge media and international shipping it actually costs $30-50.
Important things they missed out: Stability/reliabilty, security, availability, interoprability, didn't covert scalability properly...
There were some other things I thought were kinda strange...I'll concentrate on Solaris here.
For Solaris they actually used Solaris on Intel, which is fair enough considering they were looking at doing stuff on the same hardware, but isn't that good for 'real world' situations (A comparison with a Sun E450 would have been interesting) because most people who use Solaris use it on Sun hardware. Some things are a bit unclear - they seem to say they got the Solaris box from Sun, even though Sun don't sell Intel based boxes themselves - they get OEMs to do that. (actually, they correct that later, saying that Sun brought in a Dell PowerEdge box) They don't say when they got the box, but they did mention Sun's Project Cascade (think Samba for Solaris) but didn't mention that products for this are now available (well, availability was annouced a few weeks back, though I don't know about x86 versions).
They gave Solaris (on Intel) a D on RAID due to lack of support for PCI cards (not sure how fair that is) which is kinda funny when Solaris on SPARC has about the best and most reliable RAID setup out there, according to people I've talked to.(NetApps were also highly praised btw) They then criticize Sun for being 'expensive' (the hardware is, sure), when they were not even testing Sun hardware, while Solaris itself is actually very cheap for a commercial OS. (NT is only cheaper than Solaris when your NT box has no clients) They then have contradictory stuff about Solaris - stuck in the datacenter on some pages (the main ones), while on other pages (the Solaris specific ones) they give a different picture...
Btw, in the final page about Solaris they mention a report from the Standish group, but they don't give a URL to it. It's available here - Solaris Vs NT.
The E10000 does it now. The E3500, E4500, E5500, E6500 are all hardware capable of doing the exact same thing! But Sun isn't offering that feature in their operating system.
Unless I'm mistaken, you can do DR on all the Ex5000 now, so long as you have Solaris 7. The E10000's have had it for 2 years, but then Sun merged the special stuff for this into standard Solaris, for Solaris 7.
Thin clints are probably the right way to go for the enterprise... much more stable, easy to maintain... it would save loads of support costs. But for the home user? Who's gonna be my server?
I agree that it'll happen first, and fastest, on the enterprise. As for your server, it'll be your 'ISP', though that isn't really the right term for it. It'll be a service provider in general - yesterday Sun were making a big deal about this with their 'serviceprovider.com' thing... The reason why some things will take longer at home is simply due to bandwidth, or lack thereof (though this will be solved over time). If you're mostly downloading stuff, current cable modems might do. If you're editing 'big' files, then you'll start having trouble, at the moment - but when people often have 2Mbit each way, things'll be more interesting...
Maybe an "internet appliance" is fine for most things but what about us programmers? What about Photoshop and 3D Studio? Are there really viable alternatives that can handle thousands of users compiling and running filters and rendering 3D? Can a "thin client" run Quake3?
Since when did I say that it was for everybody? In fact, I clearly stated at least twice that it wouldn't 'do' for geeks. As for Quake3, how about all the new games machines - Q3 on Playstation-2, yum yum. The more recent (and upcoming) game machines make much ado about internet connectivity as standard. Some guys from Sony were saying that it could end up being a 'centre' for home networks - enter Jini, HAVi et all.
Btw, 'thin client' does NOT mean there is no hard disc (or equivilant). It does not mean 33Mhz 386. Remember the recent Intel stuff about the StrongARM 2? Cheap little embedded processor that goes up to 600Mhz. Guess what it will targeted at...? It's kinda hard to define 'thin client' - think of something around an old Atari or Amiga, but with at least 200Mhz processor, 16MB RAM, 'internet connectivity' as standard, etc. OS would probably (mostly) come in ROM, or similar...
There are lots of "computer enthusiasts" (not even counting us hardcore geeks) that would be appalled by the idea of not having a local drive or their own software. And how would software licensing work? Subscriptions? Blehh...
'thin client' != 'no hard disc'. It might have a notebook size one, it might even have one of those IBM micro ones, it might have flash ram, or other type of NV (non-volatile) RAM, it might have an Orb drive or Zip drive or re-writable CDROM...
Software licensing will be interesting... lots of possibilities. Here's a little piece by Scott 'I polish by teeth everyday' McNealy titled Stop buying software
Their is a future for Scott's vision I'm sure... but there will ALWAYS be a market for REAL home computers with REAL OSs, IMHO
Obviously.
Some people (in the press, and from some corporations) have been banding around the 'death of the PC'. Perhaps they should have said 'death of the PC culture', though I guess that's harder to fit into a headline. They don't mean the PC'll disappear, but that it will be 'sidelined' - it won't have the crown anymore.
There's less of a reason that there used to be, but basically the reason why Sun execs (and Oracle ones for the matter) are 'always' bashing MS is they realised some time ago that they're far more likely to get an article published about them if they bash MS. Scott and Larry Ellison (from Oracle) have done some pretty crazy things in the course of bashing MS, and in many ways it's just so that more people will actually listen to them and not just ignore them for not being MS. Things have changed somewhat in the last 6 months though - the media are much less MS puppy-dogs, and are a lot more open to Sun (and others') ideas.
Here's a somewhat amusing 'top 10' dig Scott did a while ago: (taken from a VAR Business article) Sure it's sophomoric, but Bones can't help but get a good chuckle every time Sun CEO Scott McNealy comes out with a top 10 list about Microsoft. He had the 800 or so attendees howling at Sun's annual reseller shindig last week at the Marriott Palm Desert near Palm Springs, Calif. É Drum roll É The Top 10 signs your pacemaker is running Windows: 10. When you wake up in post-op, Intel Inside is stamped on your chest. 9. Every year, you need an upgrade operation. 8. Every few minutes, without warning, your heart reboots. 7. Your heart works, but you can't get that loving feeling anymore. 6. Your wife starts calling you Micro Soft. 5. You discover that Pacemaker 98 doesn't scale past sleepwalking or four holes of golf. 4. Your head nurse looks suspiciously like Janet Reno. 3. Y2K scares you to death. 2. You realize it isn't only the hospital gown that leaves your rear exposed. 1. You're dead.
Some time ago I submitted a load of links to Slashdot, but they didn't get published. Here they are:
While Linux will pose more of a threat in the long-term, currently it's helping Sun. Here's some recent Sun-related links - Sun does well according to
IDC server survey. Sun's sha re price has risen from $20 to $70 in last 6 months. Sun is now selling the Samba-like NetLink (part of Project Cascade). Interview with Scott McNealy (Sun CEO) at The Register, parts one, two, three and four - "the enemy of my enemy is my friend, so I love Linux.". A SunWorld (not part of Sun) article about the "unoperating system" - Oracle (and Sun's) plans for 'thin-server' appliances with a small OS.
There's also a more recent article at SunWorld about Linux on SPARC.
Here's the bit about Linux from the article at The Register:
"Linux is like Windows: it's too fat for the client, for the appliance...it's not scalable for the server. It's the right way to do the wrong answer, so if you're going to do the wrong answer which is fat clients and thin servers, then at least do it with Linux.
"Don't send any money to Microsoft for something that's fatter, slower, buggier, doesn't scale as well, and has fewer people working on it.
"There was an interesting little experiment our CTO [Bill Joy] did. He took the Sony Vaio notebook... He downloaded Linux, then he went over to Netscape and downloaded the latest version, and then he went over to Star Office, and all of a sudden he had a better, faster, smaller, lower-powered, bug-free, legally free environment... with more people working on it than the entire state of Washington.
"Now why in the world would anybody ever write another cheque to Microsoft? I don't know. But why would you do Linux either? That's the wrong answer. Go thin clients, go appliances: that's the right way to go long term. So that's why I call [Linux] the right way to do the wrong answer. And the enemy of my enemy is my friend, so I love Linux."
Okay, some comments on this. If you include all the GNU/XFree86 as being part of Linux then it becomes pretty damn big. XFree86 is something like 45 million lines of code, last I heard. So 'all' of GNU/Linux is about 60 million, perhaps. Solaris is about 10 million. However, Scott's take on the future is basically the network computer concept. However, the markets he's thinking of are a) corporate, b) embedded consumer systems (TVs, set-top-boxes, intelligent phones etc) and not geeks. So, you have 'big iron' servers in the background giving you extreeme reliability - as reliable as phones, and incidentaly about 20% of Sun's revenue comes from telcos. These manage the 'master records' of your files, data etc. You then have 'simple' local clients that can do their own processing and have access to your 'big iron' servers.
As an example, just recently, Sun announced their 'i-Planet' software, which is very cute - all you need is 'client' computers with Java running on it, and some servers in the background, with both connected to the internet. Now, what you do is from anywhere on these client computers you 'login' to the server, which then sends you some Java programs so that you can securely manage/access your email and other things. Basically, you don't need a 'personal' computer anymore.
Scott's "right way to do wrong answer" is kinda misleading. But you can look at it like this, a) he thinks Linux is 'good' for what it is supposed to do, b) he thinks that (currently) Linux is not a general solution to the various problems that need to be solved in computing - ie it solves a sub-set. Scott's general 'solution' is for big (Sun) servers in the background with 'thin clients' being used the the public/workforce running Java - the hardware/OS doesn't even have to be from Sun.
Is he right? Well, I think that for many situations I think 'thin client' 'network computing' is a good way to do many things, but it's not really for hacker types. How well the implimentation works will depend on the software, which is why NCs didn't take off - the software wasn't ready.
There's an article about HotSpot at news.com here. They say Sun changed their minds and decided to make it free. (Sun's stuff doesn't seem to be particularly clear...)
The future of compilation, IMHO, is compiling your code with profiling information included, running your app for awhile, and then feeding the profile back into the compiler for more information to generate your final optimized executable.
Sun's professional C/C++ compilers already do this. (I presume there are other C/C++ compilers out there that do the same). It also has some nice run-time checking for memory-leaks...
IBM's latest: 22.6 SPECjvm (1x 350Mhz PII on NT4) Fast JVM: 29.1 SPECjvm (1x 500Mhz Alpha EV6 on Tru64 Unix) HotSpot: 31.1 SPECjvm (2x 450Mhz PII on NT4) HotSpot: 31.9 Specjvm (1x 450Mhz UltraSparc-II with Solaris 7)
(don't ask me what diff the dual PII's made for the HotSpot one. unfortunately they don't publish result for single-processor) Also, the 450Mhz UltraSparc-II won't be out for a few more weeks. A 450Mhz PII has 17.2 SPECint95 and 12.9 SPECfp-95. A 450 Mhz UltraSparc-II has 19.6 SPECint95 and 27.1 SPECfp95. A 500Mhz EV6 Alpha is rated as 27.3 SPECint95, and 57.7 SPECfp95.
I don't have general volano marks available. Also, you can probably see what Sun are initially targeting HotSpot mostly at server side (for now anyway) as the effect is much greater compared to client side (because the longer HotSpot runs for the faster it gets, and because client side has much more interaction with the OS). Check the the article on 'real world' apps posted at the top. 2x, and up to 4x faster in heavy duty real world server apps compared to other recent JVMs is pretty good. The beta-testers particularly praised the high-speed, low latency garbage collector. (wha-hey, Sun build a better bin!).
As a final note, HotSpot will be getting faster (the 2nd release will apparantly be 30% faster), as will everyone else's of course.
Back at the start many JVMs were purely interpreted, and didn't have JITs, so compared to them, HotSpot will be much faster. Also, the early ones scaled very badly for multi-processor stuff. It's possible that on complex, MP server apps HotSpot really is be 50x faster compared to JVMs from 2 years ago. *shrug*
Incidentally, that 2x faster is compared to very recent JVMs. Some apps went 4x faster. (read the links I gave).
It far easier to do this sort of thing in places where computer adoption is much smaller, as a percentage. MS is well 'established' in the US, and quite a few other countries, but not South Africa. Basically, you're not fighting against 'network effects' - ie because Tom, Dick and Harry do it, you do it too.
I don't suppose you've been using lmbench have you? I had someone quoting me Linux VS Solaris on Sparc the other day, using lmbench, and was somewhat dubious as to the results. That's not to say they were rigged, but more like they were not representative of real world situations, especially since I have used Solaris, Linux and also FreeBSD in real world server situations for quite a while.
For a bit of fun, the other day, I wrote a simple little Perl script to do some simple benchmarking: #!/usr/bin/perl
use strict; use Time::HiRes qw(gettimeofday);
my $test_dir = "t/"; my @tests = (\&create_files,\&delete_files);
foreach my $no_files (10, 30, 100, 300, 1000, 3000, 10000) { foreach my $test (@tests) { my $start_time = gettimeofday(); my $name = &$test($no_files); my $end_time = gettimeofday(); printf("%6d %10s: %s\n", $no_files, $name, 1000*($end_time-$start_time) / $no_files); } }
exit(0);
sub delete_files { my ($max) = @_; my $num; foreach $num (1..$max) { my $file = $test_dir.$num; unlink($file) || die "Failed to delete '$file':$!"; } return "Delete files"; }
sub create_files { my ($max) = @_; my $num; foreach $num (1..$max) { my $file = $test_dir.$num; open(DA_FILE, "> $file") || die "failed to open '$file':$!"; close(DA_FILE); } return "Create files"; }
The Solaris 2.6 system above is a 270Mhz Ultra 5, with a simple SCSI setup. The Linux 2.2 system is a 400Mhz PII system with striped SCSI - ie it had the better discs as well as processor. I did also benchmark a 3 year old Ultra2 (it had a 200Mhz UltraSparc-II - I didn't even know they went that slow!) but that had Solaris 7, and I put file-journaling on (file-jounaling is a standard option on Solaris 7, even free Solaris 7 for x86) - but I don't have the exact numbers for that. But it was pretty steady at around 2ms per file for create/delete, even up to 10000 files. I've also benchmarked on a Solaris 7 x86 (300 Mhz K6-2) with an IDE drive, which was a bit faster than the Ultra2 system - for file creation, it was faster than the Linux system above, for the 10000 files value. Sorry I don't have the exact numbers - the two Solaris 7 boxes aren't available to me at the moment. (this looks dodgy I know, but I wasn't expecting to be quoting these figures right now)
Incidentaly, on FreeBSD (2.2.8 anyway) it was a bit slower than Solaris 2.6 on a similarly spec'ed machine.
I criticise lmbench above. The same criticism can be equally applied to my program - it's pretty rare you get cases like this.
I certainly don't have much problem accepting that the standard Linux FS is faster than the standard Solaris FS. However, I do know that the Linux FS does cache very agresively. Some would say too much - problems with file-system integrity are much more common on Linux than Solaris or FreeBSD. This also means that if memory useage is heavy, the Linux file-system will slow down much more compared for FreeBSD and Solaris. Basically, with the Linux fs even though the operation has completed, what is on the hard disc is another matter. Because they cache much less for writes, on FreeBSD and Solaris when the tests finish, the hard disk is up to date, ignoring the hard disc's own cache. (I'm only mentioning FreeBSD and Solaris because that's what I've used. It would be pretty similar on other Unix systems)
So, for the file-system, Linux has sacrificed some stability and reliability for performance. For desktop users this probably isn't too bad, but I (most sysadmin I know agree) wouldn't find it acceptable for anything 'mission critical'. Indeed, I have had a Linux installation die on me, and have had to bounce Linux servers, which always makes me kinda nervous. I've also seen Linux run fsck on bootup, even when I did a 'clean' reboot. However, on Solaris 7 (with file journaling on) fsck doesn't even need to be run on bootup because of the way file jounaling works. (incidentally, you can even turn file journalaing on/off under Solaris 7 while the system is running)
On another note, Linux does have a file jounaling file system in the works (I don't know if it is a full log file system) which would make things even faster, and also, more reliable. However, Solaris does have full log file systems available now (there's one from Sun, another from Veritas, and maybe even others), and they have been available for some time. (you just gotta pay for them). Most other commercial Unixes have file logging/journaling.
I have also seen cases where for servers under heavy load, Solaris could cope, but Linux couldn't - this was on indentical x86 hardware. This does reflect that fact that Solaris scales better than Linux. You can actually see this on the values I quote above - as the number of files in increased, the speed under Solaris was pretty constant, but with Linux it started to slow down - basicaly as the limits of Linux's cachine was started to being pushed.
However, this all proves very little because nothing I have shown here is even close to being a proper test. I'm not an expert on these things either... but maybe it'll give you some things to think about.
To me, there seems to be a strange belief that all the proprietary Unix companies are just going to keel over, or switch to Linux. In the long term, Linux will certainly start to hurt these companies, but at the moment, it's actually kinda helping them. The proprietary Unix guys make most of the revenue and profit from hardware, not software, so they don't really care if people buy their hardware and run Linux on it. Linux is actually helping the others with a general "return to unix". Not all vendors are being effected the same - last year, Sun's revenue was up about 30%, HP's up 15%, IBM static, Compaq/DEC static, and SGI a fair bit down. Of them Sun is the only one to not sell NT boxes. The only big computer hardware company to have done better last year than Sun was Dell. However, Sun are expected to continue to do well this year, while Dell, not as good.
Side note, for the purpose of this reply, 'high end' means the hardware alone costs several million, while 'low end' means it costs a few thousand.
From a short-term financial point of view, there's little motivation for people like Sun, to make a complete 'conversion' to Linux. Also, think about this - the Unix vendors are generally big on the high-end (enterprise, data-center level) while Linux is big at the small end, which is also where Microsoft is big at. So, Linux is/will be hurting Microsoft more than the Unix vendors. Also, because most Linux's development is at the low end, it doesn't have 'enterprise' level features (I mean Enterprise, not server), and for Enterprise customers there's little that Linux offers over the 'costly' Unixs (the software is generally pretty cheap compared to the hardware) and they're the kind of people who least like to change - why do you think the mainframe hasn't died off yet?
Because for Compaq their 'Tru64' unix doesn't comprise than many Alpha sales, they're the most likely to drop it. However, for the others, it's kinda different - first, they simply couldn't just move everything to Linux, they'd have to add features first, which means either waiting for the Linux community to do it (probably in an incompatible way with how they did it), or do it themselves, which costs. In fact the development costs for each of the commercial unix companies could be pretty bad - remember they have to re-test everything, etc, retrain their staff, convince their own development teams (quite a few of which might just leave), get their solutions government certified again, and so on. Then they have to persuade their customers to change, which means big costs for the customers, with probably little improvement from a functionality point of view.
This would takes years, and cost billions. There'd be quite a few customers who would not want to change either, pretty much no matter what, and quiet a few customers might 'defect' to other commercial unixs. They'd also have to continue supporting both their own Unix and Linux for a while (Sun is still supporting Solaris 2.3, which has been around for over 5 years), which probably means taking on extra staff...
Unless there is huge pressure from their customers (very little so far), the commercial unix guys aren't going to make big changes anytime soon. Things will slowly change over time though. Already the commercial guys are making it easier to run Linux on their own hardware. Sun have already announced and demonstrated software to let Linux apps run under Solaris. Pretty minor projects. Linux will first start to 'attack' the commercial guys at the low end, and slowly (over many many years) work up towards the high end. Likewise, the vendor's efforts to accommodate, integrate with, and 'combat' Linux will increase.
Still, the above companies aren't going to feel financially pinched by Linux until it starts reducing their hardware sales. And since for mid to high-end hardware, it's mostly the proprietary guys anyway, as long as they don't loose out to new companies in this area (like Dell), since they'll be still selling their profitable hardware (whatever OS it runs) they're probably not going to be hurting for quite some time...
To sum up, Linux is attack the low end, the home ground of Microsoft the principal competitor for the proprietary guys, while have the high end, which tends to be very conservative and moves slowly. That is why Linux will out sell the commercial guys in numbers, but make much less revenue for quite a few years to come.
The author mentioned articles in The Register, and other places, but seemed to just ignore the content of those articles. He is right about the compiler though - it is a big issue, and I've heard it isn't going too well.
Incidentaly, what I've heard at the Register does correspond pretty well what I've heard though other channels.
Basically, the 'other' problems with the Merced are the design itself - Intel's engineers aren't used to doing this sort of thing, and also, apprantly they're a bit short on quality engineers, and are using lots of people who've just left university. Not the sort of people to give a massively complicated chip design to.
Incidentaly, the '2nd gen' EPIC chip, the McKinley is mostly being done by HP, and is apprantly going pretty well. I've been hearing from my own contacts for a long long time, that the Merced might just end being a 'test' processor that never goes into production, and that the McKinley will be the first production EPIC.
Not surprisingly both HP and SGI have recently been saying they'll still commited to their own architectures (at least for a while), after previously planning to dump them. I think HP have been saying they'll go with their own stuff for another 5 years.
Intel isn't the only one being a bit late. Sun are about a year behind with their UltraSparc-III, though I haven't heard anything about why they're behind. (their reasons for being late is probably quite different to Intels.) Shame, as it seems like a pretty nice chip...
Slashdot Mirror
The system-boards/motherboards are $10,000 each, not $100,000, I believe. Still, a 2GByte memory module from Sun for the Starfire costs $10,000 to, if memory serves. The case alone (with no system-boards) costs $200,000 or something.
A single Starfire is rated as being able to deliver 99.95% availability with one - ie no clusters, and without all those caveats above - though it does need to be setup with reliability in mind for this - there's plenty of options.... Starfires aren't simple either - up to 64 CPUs, many more PCI and similar slots, memory slots, etc, etc. So, plenty of things to go wrong. Similar sized computers (from everyone) are really hard to transport without something going wrong. The only people more nutso on reliability on 'big iron' computers are IBM (from the companies I know a fair bit about anyway). Not only do they have backup CPUs, in their CPUs they do the same operation twice (in parallel, with checking at the end) to trap the ultra-freak chance of cosmic radiation or something casuing a flipped bit, or worse. (yes, they do seriously actually worry about such things... I remember an IBM proposal about how to design memory that can handle a once-a-month chance, for when you have a huge about of RAM, for some particular kind of radiation....)
The only complaint I've ever heard about Starfires in general is that if a PCI card (though not SBus card) breaks down it can hang the entire system until an operator manually flicks a switch to say that that particular card is defunct. Though this is really because of how PCI works - Sun's 99.999% reliable Netra 1800 has some highly specialised custom hardware to get around this problem with PCI cards, as well as backup CPUs and plenty of other stuff... ridiculously expensive too, they are... though apparantly more cost effective than anything in the same class. The Netra 1800s are a few months old, while the Starfire design is over 2 years old, btw.
I dunno about all of MS's claims, but I'm pretty damn sure that you can have hardware redundancy for just about everything, if you want, including the Ultra-5 controller. Most of the other claims seem to be related to the fact that you can hot-swap PCI cards, memory, CPUs and even mother-boards in a Starfire...
EBay do seem to have had more than their fair share of problems though... quite a few hardware problems it seems - I vaguely remember a problem earlier in the year was due to some controller card or something. As far as I know, nobody has had anything close to the problems EBay are having with their Starfire(s)...
Another little point... MS's idea of expensive downtime is $10,000/hour. I remember reading something on Sun's site a while back about high end availability systems. Sun's idea of expensive downtime is $10,000,000/hour - ie stockbrokers. They also had a list of most common causes for 'unplanned' downtime on their HA systems - first was 'operator error' (or lack of training, etc). I can't remember was second was, but third was 'fire'! (I'm pretty sure Sun's computers don't have a reputation for spontaneous combustion!)
Putting it another way, a particular bit of hardware becomes less important, and instead the data and services become more important. So, say within a business, you can log onto any (or most, at least) computers around, and you get the same data, same functions, same customised desktop at each and every place. Or, instead of taking a laptop or handheld, you login remotely (at the hotel, airport, general kiosk, whatever) and access your stuff like that. Or you just borrow a handheld/laptop from anywhere, and providing it has the required client stuff, then it takes little effort to 'customise' it, because your particular settings and files are exportable.
An example of this sort of thing is Sun's recently released i-Planet software. All you need is a bit of hardware, with Java and internet access, and (without taking any software with you at all, just as password) you can remotely, and securely, get access to your mail, files, etc from it. (of course, you do need the required server stuff setup first.)
Windows is very badly suited to doing this sort of thing (in general, not just the i-Planet example), though Microsoft have been cludging in some hacks around this.
To workers/members of the public, it probably won't make that big a difference for a while, unless they do lots of 'remote' work. It will make a much bigger difference to the IT departments, and sys-admin though...
Put some suggestions in a poll...
However, in the university where they work, nobody would be able to do Cold Fusion research there, even if they paid for it themselves. There is such a bad stigma attached, that it would be just impossible.
Sad huh...
It seems all the unix guys have IPv6 implimentations of some kind. Novell are 'developing' one, and supposedly Windows 2000 will have it, though I'm not sure. Not sure what the status with Apple is either, though.
Besides, since some of your apps (everything that assumes IP address is 32 bit) will need re-writing to make use of it I don't think it's going to become a really important feature anytime soon...
I dunno about IPv6 for the other unix guys, but there is a Sun provided IPv6 patch available for Solaris, and has been around since 1997 - for Solaris 2.5. Such a patch apparantly works on Solaris 7 too, though the web page doesn't say - it's bit outa date with regards to OS versions. Anybody know what the case is for Irix, and the other big boys? Besides, last I heard IPv6 hadn't even been completed yet, and I have no idea how long it'll be until it's being used significantly - ie I think bringing up IPv6 is a bit redundant when talking about current NOSs.
I wasn't particularly impressed by this article. Could have been better in a couple of ways (in some ways it seemed to have re-hashes from other articles going on about Netware VS Windows), and besides, we've seen so much similar articles it's getting boring... ^-^
PS Before someone asks, IPv6 is to replace IPv4 sometime and give us 128 bit IP addresses, instead of 32 bit. To put it simply.
btw, Sun's SCSL is aimed more at commercial developers (including Sun's OEMs) and researchers, not so much general members of the public. However, they are releasing quite a bit of stuff under the SCSL - Java, Jini, HotSpot (later this year), their SPARC processors and several other software products. They seems to be SCSL'ing their products in general. They haven't said much about SCSL'ing Solaris recently - the last time it was brought up they said it would be quite hard to do, because of all the liscences.
I suppose there will be inevitable comparisons between Beowulf and Sun's HPC software, and SMP kit. The main hardware difference is bandwidth and latency - Beowulf seems more about combining lots of single CPU (or low CPU count, eg 1-4) boxes in a network, possibly having several hundred of such boxes. Sun's approach to high end computing is to have big SMP boxes (a single Starfire E10000 can take 64 UltraSparcs) with the option of clustering a few of them - currently limited to 4, ie 256 processors. A Starfire has a 6Gbyte/s I/O bus and 15Gbyte/s main memory bus, which is rather better than Ethernet. Sun's approach is more expensive, but it also solves a wider class of problems well. For some things (eg cracking codes, rendering) you don't need much interprocess communication or bandwidth, so it scales well with Beowulf, but for other things (some kinds of database operations, eg OLAP, and data intensive scientific calculations) you really need very high bandwidth and very low latency (close to main memory speeds) which is where Beowulf doesn't do so well. Still, some things don't scale so well, even on a Starfire... Btw, the Starfire is over 2 years old.
Cue Sun's next gen super-computer, codename Serengheti, which has a completely different architecture. It's memory architecture is called Cache Only Memory Architecture (COMA), which seems to have been in development for a long long time at Sun. A single box will take 128 processors, and you'll be able to cluster 8 of them, for a total of 1024 processors. It'll be powered by Sun's UltraSparc-III, which recently reached first silicion, and has b ooted on Solaris. Incidentaly, the UltraSparc-III has hardware support for 1024 processors, and is supposed to be out in volume production by the end of the year. However, Serengheti won't be out until about the 2nd half of 2000.
How Sun got their heap allocator to be as fast as C++'s stack allocator is pretty simple, more or less. (read their white papers and data sheets for more). Basically, you have a big 'stack' just for objects, and when you get to the end, you go back to the start, and for all the old (dead) objects there (often most of them) you just clear them out, and if an object is still live then you move it to a different block, where objects are expected to last longer, and has a more complicated algorithm to keep things tidy. Of course, if you're allocating huge numbers of objects that last a long long time, then Sun's method will slow down... though any method would (but if you know you're going to do this, you could make the heap bigger)
PS Your code example is just dead code, so a C compiler would just drop that code. HotSpot will also do this optimisation.
1) if you're going to use HotSpot, read all the docs. It's quite easy to write a simple 'benchmark' that goes really slow on HotSpot. (then change about 2-3 lines and it goes 20x faster)
2) Performance really does vary a lot. Best are predominantly Java server-apps - typical speed-up is 2-4 fold.
3) Client/graphics don't change up because most of the time running for them is in the binaries, not Java byte-code. According to Java's creator, the graphics guys are spending all their time making the code faster and leaner the moment...
4) JavaWorld HotSpot article - checkout the VolanoMark scalability on Solaris - WOAH! (half way down)
5) Apps with heavy object usage really do benifit. I've seen one example with a compiler with a C++ and Java version. The Java version with HotSpot was 50% faster than the C++!
6) Garbage collection and memory allocation is amazing - hardly notice garbage collection any more, and some people reckon the object allocation (on the 'heap') is as fast as C++'s on the stack! (in C++, allocating to the stack is much faster than the heap)
7) The HotSpot code was designed to be highly portable
8) HotSpot is free to use.
9) HotSpot will come out under Sun's "Community Source liscence" in about 6 months. (enough time to patent everything?)
Sun UK used to do it completely free (they'd order it for you from the US) but stopped doing it because of excessive demand.
There were some other things I thought were kinda strange...I'll concentrate on Solaris here.
For Solaris they actually used Solaris on Intel, which is fair enough considering they were looking at doing stuff on the same hardware, but isn't that good for 'real world' situations (A comparison with a Sun E450 would have been interesting) because most people who use Solaris use it on Sun hardware. Some things are a bit unclear - they seem to say they got the Solaris box from Sun, even though Sun don't sell Intel based boxes themselves - they get OEMs to do that. (actually, they correct that later, saying that Sun brought in a Dell PowerEdge box) They don't say when they got the box, but they did mention Sun's Project Cascade (think Samba for Solaris) but didn't mention that products for this are now available (well, availability was annouced a few weeks back, though I don't know about x86 versions).
They gave Solaris (on Intel) a D on RAID due to lack of support for PCI cards (not sure how fair that is) which is kinda funny when Solaris on SPARC has about the best and most reliable RAID setup out there, according to people I've talked to.(NetApps were also highly praised btw) They then criticize Sun for being 'expensive' (the hardware is, sure), when they were not even testing Sun hardware, while Solaris itself is actually very cheap for a commercial OS. (NT is only cheaper than Solaris when your NT box has no clients) They then have contradictory stuff about Solaris - stuck in the datacenter on some pages (the main ones), while on other pages (the Solaris specific ones) they give a different picture...
Btw, in the final page about Solaris they mention a report from the Standish group, but they don't give a URL to it. It's available here - Solaris Vs NT.
Unless I'm mistaken, you can do DR on all the Ex5000 now, so long as you have Solaris 7. The E10000's have had it for 2 years, but then Sun merged the special stuff for this into standard Solaris, for Solaris 7.
I agree that it'll happen first, and fastest, on the enterprise. As for your server, it'll be your 'ISP', though that isn't really the right term for it. It'll be a service provider in general - yesterday Sun were making a big deal about this with their 'serviceprovider.com' thing... The reason why some things will take longer at home is simply due to bandwidth, or lack thereof (though this will be solved over time). If you're mostly downloading stuff, current cable modems might do. If you're editing 'big' files, then you'll start having trouble, at the moment - but when people often have 2Mbit each way, things'll be more interesting...
Since when did I say that it was for everybody? In fact, I clearly stated at least twice that it wouldn't 'do' for geeks. As for Quake3, how about all the new games machines - Q3 on Playstation-2, yum yum. The more recent (and upcoming) game machines make much ado about internet connectivity as standard. Some guys from Sony were saying that it could end up being a 'centre' for home networks - enter Jini, HAVi et all.
Btw, 'thin client' does NOT mean there is no hard disc (or equivilant). It does not mean 33Mhz 386. Remember the recent Intel stuff about the StrongARM 2? Cheap little embedded processor that goes up to 600Mhz. Guess what it will targeted at...? It's kinda hard to define 'thin client' - think of something around an old Atari or Amiga, but with at least 200Mhz processor, 16MB RAM, 'internet connectivity' as standard, etc. OS would probably (mostly) come in ROM, or similar...
'thin client' != 'no hard disc'. It might have a notebook size one, it might even have one of those IBM micro ones, it might have flash ram, or other type of NV (non-volatile) RAM, it might have an Orb drive or Zip drive or re-writable CDROM...
Software licensing will be interesting... lots of possibilities. Here's a little piece by Scott 'I polish by teeth everyday' McNealy titled Stop buying software
- Their is a future for Scott's vision I'm sure... but there will ALWAYS be a market for REAL home computers with REAL OSs, IMHO
Obviously.Some people (in the press, and from some corporations) have been banding around the 'death of the PC'. Perhaps they should have said 'death of the PC culture', though I guess that's harder to fit into a headline. They don't mean the PC'll disappear, but that it will be 'sidelined' - it won't have the crown anymore.
Here's a somewhat amusing 'top 10' dig Scott did a while ago:
(taken from a VAR Business article)
Sure it's sophomoric, but Bones can't help but get a good chuckle every time Sun CEO Scott McNealy comes out with a top 10 list about Microsoft. He had the 800 or so attendees howling at Sun's annual reseller shindig last week at the Marriott Palm Desert near Palm Springs, Calif. É Drum roll É The Top 10 signs your pacemaker is running Windows:
10. When you wake up in post-op, Intel Inside is stamped on your chest.
9. Every year, you need an upgrade operation.
8. Every few minutes, without warning, your heart reboots.
7. Your heart works, but you can't get that loving feeling anymore.
6. Your wife starts calling you Micro Soft.
5. You discover that Pacemaker 98 doesn't scale past sleepwalking or four holes of golf.
4. Your head nurse looks suspiciously like Janet Reno.
3. Y2K scares you to death.
2. You realize it isn't only the hospital gown that leaves your rear exposed.
1. You're dead.
There's also a more recent article at SunWorld about Linux on SPARC.
Here's the bit about Linux from the article at The Register:
"Don't send any money to Microsoft for something that's fatter, slower, buggier, doesn't scale as well, and has fewer people working on it.
"There was an interesting little experiment our CTO [Bill Joy] did. He took the Sony Vaio notebook ... He downloaded Linux, then he went over to Netscape and downloaded the latest version, and then he went over to Star Office, and all of a sudden he had a better, faster, smaller, lower-powered, bug-free, legally free environment ... with more people working on it than the entire state of Washington.
"Now why in the world would anybody ever write another cheque to Microsoft? I don't know. But why would you do Linux either? That's the wrong answer. Go thin clients, go appliances: that's the right way to go long term. So that's why I call [Linux] the right way to do the wrong answer. And the enemy of my enemy is my friend, so I love Linux."
Okay, some comments on this. If you include all the GNU/XFree86 as being part of Linux then it becomes pretty damn big. XFree86 is something like 45 million lines of code, last I heard. So 'all' of GNU/Linux is about 60 million, perhaps. Solaris is about 10 million. However, Scott's take on the future is basically the network computer concept. However, the markets he's thinking of are a) corporate, b) embedded consumer systems (TVs, set-top-boxes, intelligent phones etc) and not geeks. So, you have 'big iron' servers in the background giving you extreeme reliability - as reliable as phones, and incidentaly about 20% of Sun's revenue comes from telcos. These manage the 'master records' of your files, data etc. You then have 'simple' local clients that can do their own processing and have access to your 'big iron' servers.
As an example, just recently, Sun announced their 'i-Planet' software, which is very cute - all you need is 'client' computers with Java running on it, and some servers in the background, with both connected to the internet. Now, what you do is from anywhere on these client computers you 'login' to the server, which then sends you some Java programs so that you can securely manage/access your email and other things. Basically, you don't need a 'personal' computer anymore.
Scott's "right way to do wrong answer" is kinda misleading. But you can look at it like this, a) he thinks Linux is 'good' for what it is supposed to do, b) he thinks that (currently) Linux is not a general solution to the various problems that need to be solved in computing - ie it solves a sub-set. Scott's general 'solution' is for big (Sun) servers in the background with 'thin clients' being used the the public/workforce running Java - the hardware/OS doesn't even have to be from Sun.
Is he right? Well, I think that for many situations I think 'thin client' 'network computing' is a good way to do many things, but it's not really for hacker types. How well the implimentation works will depend on the software, which is why NCs didn't take off - the software wasn't ready.
Sorry this isn't very well written...
There's an article about HotSpot at news.com here. They say Sun changed their minds and decided to make it free. (Sun's stuff doesn't seem to be particularly clear...)
Sun's professional C/C++ compilers already do this. (I presume there are other C/C++ compilers out there that do the same). It also has some nice run-time checking for memory-leaks...
A HotSpot beta-tester wrote a long, detailed article to the newsgroups. You'll probably find it an interesting read. Find it here
Fast JVM: 29.1 SPECjvm (1x 500Mhz Alpha EV6 on Tru64 Unix)
HotSpot: 31.1 SPECjvm (2x 450Mhz PII on NT4)
HotSpot: 31.9 Specjvm (1x 450Mhz UltraSparc-II with Solaris 7)
(don't ask me what diff the dual PII's made for the HotSpot one. unfortunately they don't publish result for single-processor) Also, the 450Mhz UltraSparc-II won't be out for a few more weeks. A 450Mhz PII has 17.2 SPECint95 and 12.9 SPECfp-95. A 450 Mhz UltraSparc-II has 19.6 SPECint95 and 27.1 SPECfp95. A 500Mhz EV6 Alpha is rated as 27.3 SPECint95, and 57.7 SPECfp95.
I don't have general volano marks available. Also, you can probably see what Sun are initially targeting HotSpot mostly at server side (for now anyway) as the effect is much greater compared to client side (because the longer HotSpot runs for the faster it gets, and because client side has much more interaction with the OS). Check the the article on 'real world' apps posted at the top. 2x, and up to 4x faster in heavy duty real world server apps compared to other recent JVMs is pretty good. The beta-testers particularly praised the high-speed, low latency garbage collector. (wha-hey, Sun build a better bin!).
As a final note, HotSpot will be getting faster (the 2nd release will apparantly be 30% faster), as will everyone else's of course.
Incidentally, that 2x faster is compared to very recent JVMs. Some apps went 4x faster. (read the links I gave).
It far easier to do this sort of thing in places where computer adoption is much smaller, as a percentage. MS is well 'established' in the US, and quite a few other countries, but not South Africa. Basically, you're not fighting against 'network effects' - ie because Tom, Dick and Harry do it, you do it too.
For a bit of fun, the other day, I wrote a simple little Perl script to do some simple benchmarking:
:$!";
:$!";
#!/usr/bin/perl
use strict;
use Time::HiRes qw(gettimeofday);
my $test_dir = "t/";
my @tests = (\&create_files,\&delete_files);
foreach my $no_files (10, 30, 100, 300, 1000, 3000, 10000) {
foreach my $test (@tests) {
my $start_time = gettimeofday();
my $name = &$test($no_files);
my $end_time = gettimeofday();
printf("%6d %10s: %s\n", $no_files, $name, 1000*($end_time-$start_time) / $no_files);
}
}
exit(0);
sub delete_files {
my ($max) = @_;
my $num;
foreach $num (1..$max) {
my $file = $test_dir.$num;
unlink($file) || die "Failed to delete '$file'
}
return "Delete files";
}
sub create_files {
my ($max) = @_;
my $num;
foreach $num (1..$max) {
my $file = $test_dir.$num;
open(DA_FILE, "> $file") || die "failed to open '$file'
close(DA_FILE);
}
return "Create files";
}
# Results - the values are average time per file in mili-seconds.
#
# SPARC Solaris 2.6
# 10 Create files: 17.3946022987366
# 10 Delete files: 8.25690031051636
# 30 Create files: 16.6551351547241
# 30 Delete files: 8.31733147303263
# 100 Create files: 16.6641497612
# 100 Delete files: 8.32810044288635
# 300 Create files: 17.0558432737986
# 300 Delete files: 8.49879026412964
# 1000 Create files: 19.0030739307404
# 1000 Delete files: 8.36658298969269
#
# Linux 2.2 x86
# 10 Create files: 0.0998973846435547
# 10 Delete files: 0.678598880767822
# 30 Create files: 0.0572681427001953
# 30 Delete files: 0.0586668650309245
# 100 Create files: 0.0708794593811035
# 100 Delete files: 0.0524997711181641
# 300 Create files: 0.0964502493540446
# 300 Delete files: 0.0535901387532552
# 1000 Create files: 0.223060011863708
# 1000 Delete files: 0.0744880437850952
# 3000 Create files: 0.529780666033427
# 3000 Delete files: 0.0793236494064331
# 10000 Create files: 1.90500370264053
# 10000 Delete files: 0.145310199260712
The Solaris 2.6 system above is a 270Mhz Ultra 5, with a simple SCSI setup. The Linux 2.2 system is a 400Mhz PII system with striped SCSI - ie it had the better discs as well as processor. I did also benchmark a 3 year old Ultra2 (it had a 200Mhz UltraSparc-II - I didn't even know they went that slow!) but that had Solaris 7, and I put file-journaling on (file-jounaling is a standard option on Solaris 7, even free Solaris 7 for x86) - but I don't have the exact numbers for that. But it was pretty steady at around 2ms per file for create/delete, even up to 10000 files. I've also benchmarked on a Solaris 7 x86 (300 Mhz K6-2) with an IDE drive, which was a bit faster than the Ultra2 system - for file creation, it was faster than the Linux system above, for the 10000 files value. Sorry I don't have the exact numbers - the two Solaris 7 boxes aren't available to me at the moment. (this looks dodgy I know, but I wasn't expecting to be quoting these figures right now)
Incidentaly, on FreeBSD (2.2.8 anyway) it was a bit slower than Solaris 2.6 on a similarly spec'ed machine.
I criticise lmbench above. The same criticism can be equally applied to my program - it's pretty rare you get cases like this.
I certainly don't have much problem accepting that the standard Linux FS is faster than the standard Solaris FS. However, I do know that the Linux FS does cache very agresively. Some would say too much - problems with file-system integrity are much more common on Linux than Solaris or FreeBSD. This also means that if memory useage is heavy, the Linux file-system will slow down much more compared for FreeBSD and Solaris. Basically, with the Linux fs even though the operation has completed, what is on the hard disc is another matter. Because they cache much less for writes, on FreeBSD and Solaris when the tests finish, the hard disk is up to date, ignoring the hard disc's own cache. (I'm only mentioning FreeBSD and Solaris because that's what I've used. It would be pretty similar on other Unix systems)
So, for the file-system, Linux has sacrificed some stability and reliability for performance. For desktop users this probably isn't too bad, but I (most sysadmin I know agree) wouldn't find it acceptable for anything 'mission critical'. Indeed, I have had a Linux installation die on me, and have had to bounce Linux servers, which always makes me kinda nervous. I've also seen Linux run fsck on bootup, even when I did a 'clean' reboot. However, on Solaris 7 (with file journaling on) fsck doesn't even need to be run on bootup because of the way file jounaling works. (incidentally, you can even turn file journalaing on/off under Solaris 7 while the system is running)
On another note, Linux does have a file jounaling file system in the works (I don't know if it is a full log file system) which would make things even faster, and also, more reliable. However, Solaris does have full log file systems available now (there's one from Sun, another from Veritas, and maybe even others), and they have been available for some time. (you just gotta pay for them). Most other commercial Unixes have file logging/journaling.
I have also seen cases where for servers under heavy load, Solaris could cope, but Linux couldn't - this was on indentical x86 hardware. This does reflect that fact that Solaris scales better than Linux. You can actually see this on the values I quote above - as the number of files in increased, the speed under Solaris was pretty constant, but with Linux it started to slow down - basicaly as the limits of Linux's cachine was started to being pushed.
However, this all proves very little because nothing I have shown here is even close to being a proper test. I'm not an expert on these things either... but maybe it'll give you some things to think about.
Side note, for the purpose of this reply, 'high end' means the hardware alone costs several million, while 'low end' means it costs a few thousand.
From a short-term financial point of view, there's little motivation for people like Sun, to make a complete 'conversion' to Linux. Also, think about this - the Unix vendors are generally big on the high-end (enterprise, data-center level) while Linux is big at the small end, which is also where Microsoft is big at. So, Linux is/will be hurting Microsoft more than the Unix vendors. Also, because most Linux's development is at the low end, it doesn't have 'enterprise' level features (I mean Enterprise, not server), and for Enterprise customers there's little that Linux offers over the 'costly' Unixs (the software is generally pretty cheap compared to the hardware) and they're the kind of people who least like to change - why do you think the mainframe hasn't died off yet?
Because for Compaq their 'Tru64' unix doesn't comprise than many Alpha sales, they're the most likely to drop it. However, for the others, it's kinda different - first, they simply couldn't just move everything to Linux, they'd have to add features first, which means either waiting for the Linux community to do it (probably in an incompatible way with how they did it), or do it themselves, which costs. In fact the development costs for each of the commercial unix companies could be pretty bad - remember they have to re-test everything, etc, retrain their staff, convince their own development teams (quite a few of which might just leave), get their solutions government certified again, and so on. Then they have to persuade their customers to change, which means big costs for the customers, with probably little improvement from a functionality point of view.
This would takes years, and cost billions. There'd be quite a few customers who would not want to change either, pretty much no matter what, and quiet a few customers might 'defect' to other commercial unixs. They'd also have to continue supporting both their own Unix and Linux for a while (Sun is still supporting Solaris 2.3, which has been around for over 5 years), which probably means taking on extra staff...
Unless there is huge pressure from their customers (very little so far), the commercial unix guys aren't going to make big changes anytime soon. Things will slowly change over time though. Already the commercial guys are making it easier to run Linux on their own hardware. Sun have already announced and demonstrated software to let Linux apps run under Solaris. Pretty minor projects. Linux will first start to 'attack' the commercial guys at the low end, and slowly (over many many years) work up towards the high end. Likewise, the vendor's efforts to accommodate, integrate with, and 'combat' Linux will increase.
Still, the above companies aren't going to feel financially pinched by Linux until it starts reducing their hardware sales. And since for mid to high-end hardware, it's mostly the proprietary guys anyway, as long as they don't loose out to new companies in this area (like Dell), since they'll be still selling their profitable hardware (whatever OS it runs) they're probably not going to be hurting for quite some time...
To sum up, Linux is attack the low end, the home ground of Microsoft the principal competitor for the proprietary guys, while have the high end, which tends to be very conservative and moves slowly. That is why Linux will out sell the commercial guys in numbers, but make much less revenue for quite a few years to come.
Incidentaly, what I've heard at the Register does correspond pretty well what I've heard though other channels.
Basically, the 'other' problems with the Merced are the design itself - Intel's engineers aren't used to doing this sort of thing, and also, apprantly they're a bit short on quality engineers, and are using lots of people who've just left university. Not the sort of people to give a massively complicated chip design to.
Incidentaly, the '2nd gen' EPIC chip, the McKinley is mostly being done by HP, and is apprantly going pretty well. I've been hearing from my own contacts for a long long time, that the Merced might just end being a 'test' processor that never goes into production, and that the McKinley will be the first production EPIC.
Not surprisingly both HP and SGI have recently been saying they'll still commited to their own architectures (at least for a while), after previously planning to dump them. I think HP have been saying they'll go with their own stuff for another 5 years.
Intel isn't the only one being a bit late. Sun are about a year behind with their UltraSparc-III, though I haven't heard anything about why they're behind. (their reasons for being late is probably quite different to Intels.) Shame, as it seems like a pretty nice chip...