...to males ages 15-24 is that the record companies are promoting increasingly large amounts of truly sucky music.
Personally, I fall just outside that demographic (I'm 27), and while I'm not an MP3 fiend, I go looking for them periodically. Generally the mp3s I look for are stuff that's not available on CD -- live recordings, outtakes, etc. -- or stuff that I've never heard before. I've bought several CDs precisely *because* I DLed an mp3 and liked it enough to shell out for a CD. I doubt I'm unique in that regard, and that seems to be a distribution model that hasn't even crossed the RIAA's puny little minds.
With IBM embracing Linux, I wonder if they will consider setting up an RS/6000 SP cluster running Linux.
That wouldn't be too bad. The Power2 and Power3 processors are pretty fast (although their L2 cache sizes are kinda small compared with the Alpha 21264 and MIPS R10k/R12k), and the SP switch's performance is respectable. The memory bandwidth on the SMP SP nodes is kinda sucky, though; the memory's on a shared bus, like on an SMP Intel box. It's be nice if they'd put in a memory crossbar switch like Sun uses. That'd drive the price way up, though. Compilers would be a big problem, too (just as they are now on Alpha); gcc and g77 don't cut it for high performance code.
We have an older SP-2 where I work, and we're trying get rid of it in favor of a comparably sized Beowulf. Almost everybody hates AIX and LoadLeveler (IBM's eeeevil batch system) with a passion, and the maintenance costs are murder.
--Troy
Um, no -- *you* made the claim, *you* back it up
on
Red Hat Backlash?
·
· Score: 1
Look, email Pat V., or find the old Slackware mailing list archives (if they're still around), either one of these would either verify what I was told.
You made the claim. It's your responsibility to back it up.
I was there, and I remember nothing of the sort. Slackware doesn't maintain any sort of mail archive that I can find. A Deja News power search for "bob young slackware" in comp.os.linux.* over 1/1/1994 - 1/1/1996 confirms my memory, as it turns up zero hits.
As far as the libc thing, Slackware still carries libc instead of glibc.
So? This proves what, other than the fact that Slackware's libc is horribly dated, not thread-safe, and no longer maintained by the libc developers? Debian ships with glibc too, ya know.
--Troy
What in the hell are you talking about?
on
Red Hat Backlash?
·
· Score: 1
Bob Young owned a bookstore, and was on the Slackware mailing list. At some point he bought a CD burner, started selling slackware disks at a cheaper price, and spammed everyone on the Slackware list about it. He then included glibc as a way to make other distros incompatible.
...
(btw, I learned the info in the first paragraph of this post from someone closely involved in Slackware whom I met at LinuxWorld; any innacuracies are my fault.)
Uh huh. Tell me another one. I'm sorry, but I've been in the Linux community for a very long time (since Slackware 1.0 in fall of '93), and I remember nothing of the sort.
Red Hat's been its own distribution as long as it's been around; it was never based on Slackware. (Anybody else remember *.rpp files?) Red Hat's package management scheme has always been better than the rather lame way Slackware handles things. The glibc claim is ludicrous, given that that's the direction the libc architects (including H.J. Lu) are encouraging people to go.
Your acquaintance may be horribly misremembering how Slackware got started. Slackware was originally a set of patches for the SLS distribution, which was the very first commercial Linux distro on floppy and CDROM ('92-'93). Everything in SLS was freely available, but the media was extremely pricey, even for the time. Pat Volkerding made Slackware originally as a patched version of SLS, but then the SLS guy (whose name escapes me) threatened to sue Pat for using the SLS install scripts, which the SLS guy saw as his proprietary property. This was widely seen (or at least seen by me) as an attempt to keep Slackware from cutting into SLS sales, but it failed miserably. Pat wrote his own install scripts and SLS died a slow death over the following year or so. By mid-'94, Slackware was in the position that Red Hat is in now in terms of percentage mindshare.
We've seen that the g77 from egcs 1.0.3 generates code that's up to 50% slower than that generated by the Portland Group compilers's pgf77 (v3.0) on Linux/x86. My guess in that the difference between g77 on Linux/Alpha and the DEC Fortran compiler is at least as great and probably larger. The problem is, you can't legally use the DEC Fortran compiler under Linux/Alpha, and I don't think the Portland Group or Absoft have plans to support Linux/Alpha either. That leaves us with only g77, which generates fairly lousy code.
(Responses to the effect of "Use C!" will be gleefully ignored. Believe it or not, most scientific programming is still done in Fortran.)
That was only an 64 processor air-cooled T3E, the smallest one SGI makes. SGI makes Origin 2000s twice as big (128 CPU SMP) and T3Es *32* times as big (2048 CPU MPP). Also, I'd be more impressed if IBM has pointed to a more widely used (and less temperamental) benchmark than parallel POV-Ray, which ends up being mainly I/O bound. NAS Parallel Benchmark numbers would be nice.
Beowulf clusters are nice if you've got a parallel problem that only scales well out to a moderate number of processors (32-64 at most), or if price/performance matters more than raw performance. They get clobbered if the problem is bounded by I/O, communication latency, or per-CPU memory bandwidth.
Frankly, IBM has a lot more to worry about from Beowulf clusters than SGI does. Their supercomputer class machine, the SP, is just a cluster of rackmount RS/6000s with a very high speed internal network, and it has all the same problems as a Beowulf cluster relative to a more tightly coupled parallel system like a T3E or an Origin. Plus, AIX is eeeeeeevil; IRIX is much nice IMHO.
And before anybody asks, yes, I work with both traditional supercomputers (Cray T94, Cray T3E/600-136LC, SGI Origin 2000/24xR10-250, IBM SP-2/8) *and* a Beowulf cluster. We've been doing benchmarks to compare our Beowulf to our big machines; in some cases, the Beowulf wins, and in others, the big machines win. It really depends on the problem. We (i.e. my group at OSC) may be announcing some benchmark pages here in a few weeks.
only on linux, where threading is broken. on a real OS, threading means that you don't need to context switch.
How does NT, which I assume you consider a "real" operating system, swap threads on a processor without doing something equivalent to a context switch (i.e. saving register contents and process/thread state)? How is this less costly than a context switch on Linux? And why is it that NT's thread switching time is *slower* than Linux's context switching time? (BTW, SGI's IRIX schedules threads in a manner almost identical to Linux; do you consider IRIX a "fake" operating system as well?)
I submit that the Linux scheduler is written the way it is because it makes more sense from a performance perspective to have a simple single-level scheduler (where threads == processes) and make that very fast than it does to have a complex multi-level scheduler (with threads inside processes). The only difference between a process and a thread, at least from my point of view as a programmer/user on big systems like the SGI Origin 2000 and Cray T3E, is that threads have shared memory areas. That's a distinction in the process or thread's memory layout, but IMHO it's not something that should extend into the scheduler unless you're doing truly nasty things like gang-scheduling threads.
Can't Linux just balance the processes between two processors? Like if you started a whole bunch of processes at once? Could it run a few on one CPU and run the rest on the other CPU?
Well, Linux tries to do that. For instance, if you have two CPU-intensive processes (say, an RC5-64 cracker and a numerical simulation), Linux will schedule them on separate processors, and you'll get an speedup of 1.9 or so relative to running both on a uniprocessor machine. However, if your processes are I/O or memory bound, SMP systems will be at best the same as a uniprocessor system and possibly slightly slower due to contention for the memory or I/O bus.
So, if you do number crunching or heavy duty non-realtime 3d rendering, SMP probably makes sense. (It does for me, anyway; I do a fair amount of prototyping of numerical simulations on my home machine before I move them over to a Cray or SGI Origin.) For DB and web serving, it might or might not help. Most desktop users probably don't need it.
A few of those would make a damn fine Beowulf cluster.
Ever looked at the specs for ASCI Blue Mountain? It's a cluster of Origins (48 Origins with 128 CPUs each, to be exact). The network fabric is GSN a.k.a HiPPI-6400, a 800MB/s full duplex switched network. Pretty darned cool. Right now it's the fastest thing on the planet, at least on the Linpack parallel benchmark.
Name one thing that linux has that Microsoft's NT doesn't have.
AFAIK, NT can only do IP masquerading by replacing parts of the client machines's TCP/IP stack with their proprietary MS Proxy stuff, so it only works with Windows clients. Linux's IP masquerading requires no modifications to the clients' IP stacks, so you can use anything as a client. I'm pretty sure the Linux IP masquerading implementation was out first, too.
This is what we need to do when we see FUD, folks: refute it as completely, as acturately, and (most importantly) as unemotionally as possible. Going off the deep end every time an author makes a boo-boo will make us look like a bunch of raving loonies. On the other hand, I think articles like this one present the case for Open Source in the best possible way -- by presenting the *FACTS*.
Well, that tells me a little more... but not much. There are 3 different models of that particular machine, depending on whether it uses 300, 450, or 600MHz Alphas. Based on the 1 TFLOP number they quote, I'm guessing they mean the model with the 600MHz chips (the T3E-1200E/1088).
The Cray machine, which costs approximately $76 million, can perform at a peak speed of one trillion instructions per second in a narrow class of applications. It cannot sustain performance at peak speed.
Well, duh!!! Of course it can't sustain peak! There's no machine in the world that can sustain more than about 50% of peak performance on useful, real world code; usually that number's closer to 25-30% of peak. Unless SBS knows something serious about compiler technology that the rest of us haven't figured out yet, sustaining a system's peak performance is impossible.
Their 12 teraop number is very suspicious, too. They define an "op" as a 4-bit integer add. The ops they quote on the T3E are 64-bit floating-point adds and multiplies. Apples and apples? I don't think so. There aren't too many interesting problems you can do with 4-bit integers, either; maybe extremely lossy signal processing, but that's about it.
I also noticed that SBS's press release page has been taken down some time in the last day or so... I'd love to believe these guys have some kind of breakthrough, but from everything I've seen they're either extremely naive or lying out their collective butts.
Show me a LINPACK 1000x1000 or SPECfp95 benchmark and I'll *think* about considering this thing a supercomputer. Till then it's just hype.
I wonder which Cray they're comparing it to. There's more than one, after all. They're probably comparing to something slow like a Y/MP or a J90. They might look stupid if they compared to a T90 or SV1...
Slashdot Mirror
WTH is the management in Mtn. View thinking?!?!
--Troy
...to males ages 15-24 is that the record companies are promoting increasingly large amounts of truly sucky music.
Personally, I fall just outside that demographic (I'm 27), and while I'm not an MP3 fiend, I go looking for them periodically. Generally the mp3s I look for are stuff that's not available on CD -- live recordings, outtakes, etc. -- or stuff that I've never heard before. I've bought several CDs precisely *because* I DLed an mp3 and liked it enough to shell out for a CD. I doubt I'm unique in that regard, and that seems to be a distribution model that hasn't even crossed the RIAA's puny little minds.
--Troy
...does that make it a roto-router? :)
--Troy
With IBM embracing Linux, I wonder if they will consider setting up an RS/6000 SP cluster running Linux.
That wouldn't be too bad. The Power2 and Power3 processors are pretty fast (although their L2 cache sizes are kinda small compared with the Alpha 21264 and MIPS R10k/R12k), and the SP switch's performance is respectable. The memory bandwidth on the SMP SP nodes is kinda sucky, though; the memory's on a shared bus, like on an SMP Intel box. It's be nice if they'd put in a memory crossbar switch like Sun uses. That'd drive the price way up, though. Compilers would be a big problem, too (just as they are now on Alpha); gcc and g77 don't cut it for high performance code.
We have an older SP-2 where I work, and we're trying get rid of it in favor of a comparably sized Beowulf. Almost everybody hates AIX and LoadLeveler (IBM's eeeevil batch system) with a passion, and the maintenance costs are murder.
Look, email Pat V., or find the old Slackware mailing list archives (if they're still around), either one of these would either verify what I was told.
You made the claim. It's your responsibility to back it up.
I was there, and I remember nothing of the sort. Slackware doesn't maintain any sort of mail archive that I can find. A Deja News power search for "bob young slackware" in comp.os.linux.* over 1/1/1994 - 1/1/1996 confirms my memory, as it turns up zero hits.
As far as the libc thing, Slackware still carries libc instead of glibc.
So? This proves what, other than the fact that Slackware's libc is horribly dated, not thread-safe, and no longer maintained by the libc developers? Debian ships with glibc too, ya know.
Bob Young owned a bookstore, and was on the Slackware mailing list. At some point he bought a CD burner, started selling slackware disks at a cheaper price, and spammed everyone on the Slackware list about it. He then included glibc as a way to make other distros incompatible.
(btw, I learned the info in the first paragraph of this post from someone closely involved in Slackware whom I met at LinuxWorld; any innacuracies are my fault.)
Uh huh. Tell me another one. I'm sorry, but I've been in the Linux community for a very long time (since Slackware 1.0 in fall of '93), and I remember nothing of the sort.
Red Hat's been its own distribution as long as it's been around; it was never based on Slackware. (Anybody else remember *.rpp files?) Red Hat's package management scheme has always been better than the rather lame way Slackware handles things. The glibc claim is ludicrous, given that that's the direction the libc architects (including H.J. Lu) are encouraging people to go.
Your acquaintance may be horribly misremembering how Slackware got started. Slackware was originally a set of patches for the SLS distribution, which was the very first commercial Linux distro on floppy and CDROM ('92-'93). Everything in SLS was freely available, but the media was extremely pricey, even for the time. Pat Volkerding made Slackware originally as a patched version of SLS, but then the SLS guy (whose name escapes me) threatened to sue Pat for using the SLS install scripts, which the SLS guy saw as his proprietary property. This was widely seen (or at least seen by me) as an attempt to keep Slackware from cutting into SLS sales, but it failed miserably. Pat wrote his own install scripts and SLS died a slow death over the following year or so. By mid-'94, Slackware was in the position that Red Hat is in now in terms of percentage mindshare.
Care to name your source? Didn't think so.
We've seen that the g77 from egcs 1.0.3 generates code that's up to 50% slower than that generated by the Portland Group compilers's pgf77 (v3.0) on Linux/x86. My guess in that the difference between g77 on Linux/Alpha and the DEC Fortran compiler is at least as great and probably larger. The problem is, you can't legally use the DEC Fortran compiler under Linux/Alpha, and I don't think the Portland Group or Absoft have plans to support Linux/Alpha either. That leaves us with only g77, which generates fairly lousy code.
(Responses to the effect of "Use C!" will be gleefully ignored. Believe it or not, most scientific programming is still done in Fortran.)
--Troy
That was only an 64 processor air-cooled T3E, the smallest one SGI makes. SGI makes Origin 2000s twice as big (128 CPU SMP) and T3Es *32* times as big (2048 CPU MPP). Also, I'd be more impressed if IBM has pointed to a more widely used (and less temperamental) benchmark than parallel POV-Ray, which ends up being mainly I/O bound. NAS Parallel Benchmark numbers would be nice.
Beowulf clusters are nice if you've got a parallel problem that only scales well out to a moderate number of processors (32-64 at most), or if price/performance matters more than raw performance. They get clobbered if the problem is bounded by I/O, communication latency, or per-CPU memory bandwidth.
Frankly, IBM has a lot more to worry about from Beowulf clusters than SGI does. Their supercomputer class machine, the SP, is just a cluster of rackmount RS/6000s with a very high speed internal network, and it has all the same problems as a Beowulf cluster relative to a more tightly coupled parallel system like a T3E or an Origin. Plus, AIX is eeeeeeevil; IRIX is much nice IMHO.
And before anybody asks, yes, I work with both traditional supercomputers (Cray T94, Cray T3E/600-136LC, SGI Origin 2000/24xR10-250, IBM SP-2/8) *and* a Beowulf cluster. We've been doing benchmarks to compare our Beowulf to our big machines; in some cases, the Beowulf wins, and in others, the big machines win. It really depends on the problem. We (i.e. my group at OSC) may be announcing some benchmark pages here in a few weeks.
--Troy
only on linux, where threading is broken. on a real OS, threading means that you don't need to context switch.
How does NT, which I assume you consider a "real" operating system, swap threads on a processor without doing something equivalent to a context switch (i.e. saving register contents and process/thread state)? How is this less costly than a context switch on Linux? And why is it that NT's thread switching time is *slower* than Linux's context switching time? (BTW, SGI's IRIX schedules threads in a manner almost identical to Linux; do you consider IRIX a "fake" operating system as well?)
I submit that the Linux scheduler is written the way it is because it makes more sense from a performance perspective to have a simple single-level scheduler (where threads == processes) and make that very fast than it does to have a complex multi-level scheduler (with threads inside processes). The only difference between a process and a thread, at least from my point of view as a programmer/user on big systems like the SGI Origin 2000 and Cray T3E, is that threads have shared memory areas. That's a distinction in the process or thread's memory layout, but IMHO it's not something that should extend into the scheduler unless you're doing truly nasty things like gang-scheduling threads.
Can't Linux just balance the processes between two processors? Like if you started a whole bunch of processes at once? Could it run a few on one CPU and run the rest on the other CPU?
Well, Linux tries to do that. For instance, if you have two CPU-intensive processes (say, an RC5-64 cracker and a numerical simulation), Linux will schedule them on separate processors, and you'll get an speedup of 1.9 or so relative to running both on a uniprocessor machine. However, if your processes are I/O or memory bound, SMP systems will be at best the same as a uniprocessor system and possibly slightly slower due to contention for the memory or I/O bus.
So, if you do number crunching or heavy duty non-realtime 3d rendering, SMP probably makes sense. (It does for me, anyway; I do a fair amount of prototyping of numerical simulations on my home machine before I move them over to a Cray or SGI Origin.) For DB and web serving, it might or might not help. Most desktop users probably don't need it.
A few of those would make a damn fine Beowulf cluster.
Ever looked at the specs for ASCI Blue Mountain? It's a cluster of Origins (48 Origins with 128 CPUs each, to be exact). The network fabric is GSN a.k.a HiPPI-6400, a 800MB/s full duplex switched network. Pretty darned cool. Right now it's the fastest thing on the planet, at least on the Linpack parallel benchmark.
Name one thing that linux has that Microsoft's NT doesn't have.
AFAIK, NT can only do IP masquerading by replacing parts of the client machines's TCP/IP stack with their proprietary MS Proxy stuff, so it only works with Windows clients. Linux's IP masquerading requires no modifications to the clients' IP stacks, so you can use anything as a client. I'm pretty sure the Linux IP masquerading implementation was out first, too.
This is what we need to do when we see FUD, folks: refute it as completely, as acturately, and (most importantly) as unemotionally as possible. Going off the deep end every time an author makes a boo-boo will make us look like a bunch of raving loonies. On the other hand, I think articles like this one present the case for Open Source in the best possible way -- by presenting the *FACTS*.
--Troy
The Cray T3E #1024
per their about us page
Well, that tells me a little more... but not much. There are 3 different models of that particular machine, depending on whether it uses 300, 450, or 600MHz Alphas. Based on the 1 TFLOP number they quote, I'm guessing they mean the model with the 600MHz chips (the T3E-1200E/1088).
I liked the following little piece of idiocy from SBS's "About us" page:
The Cray machine, which costs approximately $76 million, can perform at a peak speed of one trillion instructions per second in a narrow class of applications. It cannot sustain performance at peak speed.
Well, duh!!! Of course it can't sustain peak! There's no machine in the world that can sustain more than about 50% of peak performance on useful, real world code; usually that number's closer to 25-30% of peak. Unless SBS knows something serious about compiler technology that the rest of us haven't figured out yet, sustaining a system's peak performance is impossible.
Their 12 teraop number is very suspicious, too. They define an "op" as a 4-bit integer add. The ops they quote on the T3E are 64-bit floating-point adds and multiplies. Apples and apples? I don't think so. There aren't too many interesting problems you can do with 4-bit integers, either; maybe extremely lossy signal processing, but that's about it.
I also noticed that SBS's press release page has been taken down some time in the last day or so... I'd love to believe these guys have some kind of breakthrough, but from everything I've seen they're either extremely naive or lying out their collective butts.
Show me a LINPACK 1000x1000 or SPECfp95 benchmark and I'll *think* about considering this thing a supercomputer. Till then it's just hype.
I wonder which Cray they're comparing it to. There's more than one, after all. They're probably comparing to something slow like a Y/MP or a J90. They might look stupid if they compared to a T90 or SV1...
--Troy