> > If FreeBSD's TCP/IP is so kewl, then why doesn't anyone submit SPECweb benchmarks using FreeBSD for the 1 CPU category? Linux wipes the floor with Solaris, AIX, Tru64, and Windows 2000.
> It's not Linux thats wiping the floor, its TUX; the tiny in-kernel httpd that is designed for TRIVIAL matters. Putting the daemon inkernel is a glaring risk. It doesn't match the completeness of other userland servers like Apache.
First, TUX pushed the kernel to be fast in general. Somebody recently announced a user space web server called X15 on the linux-kernel mailing list that is more-or-less the same speed as TUX.
Second, with respect to the comment about not "matching the completeness" of Apache. Both TUX and X15 support CGIs, and I know that TUX has a plug-in model (I wouldn't be surprised if there is a plug-in model in X15 either.) If there is a Apache module that you like, but you need a faster web server than Apache, maybe you should port the plug-in...
Finally, SpecWeb is a very real test of OS and web server performance. Something like 30% of it's output is driven by CGIs. It's not a trivial setup. Not only does it stress the networking stack, but it stresses the VM system and disk/block/vfs layer very hard too. (The working set of data on the web server can be larger than the amount of memory installed in the system.)
I know this sounds like flame bait, but I'm sick of the FreeBSD advocates claiming that they are faster than Linux when it comes to network servers. If that's true, where are the numbers to prove it?
Now does the "Trasmeta hype" seem more justified? It's now obvious why the most PC laptop manfactures are ramping up production of Transmeta based laptops.
Also, to answer why people would buy that Vaio:
The Sony Vaio PictureBook at 2.2 pounds is like a motorcycle.
The PowerBook on the other hand weighs in at 6.1 pounds and is like a SUV.
Now asking why somebody would buy a motorcycle when they can buy a SUV sounds silly, doesn't it?
"Linux pthreads" is really just a library implemented on top of the Linux kernel clone() system call. The clone API scales just fine. The pthreads library on the other hand has "issues."
ROMs are slow. Ask any true Mac geek about ROM-in-RAM accelerators for traditional Mac OS (version 9 and below). Why? Modern SDRAM latency is less than 10ns. ROM latency is about 150ns. Need I say more?
Correction. Altivec provides 32 128 bit registers that can be individually treated as:
4 32 bit floating point numbers
4 32 bit signed/unsigned integers
8 16 bit signed/unsigned integers
16 8 bit signed/unsigned integers
AltiVec provides extremely powerful SIMD instructions, and even special instructions targeted at graphics (convert between 16 bit and 32 bit pixels with one instruction).
Ouserhout didn't "turn around" his opinion on threads. He still believes that threads have their place in programming. He was simply trying to point out that threads aren't the panacea for all your programming ills, despite what industry hype would seem to suggest.
Yes, I would implement a client-server system with only one thread per processor. Keep in mind that each thread would be doing event driven I/O for potentially hundreds or thousands of connections.
The fact that the IBM guys are suggesting to change Linux to make up for deficiencies in the Java language seems extremely absurd to me.
Threads are an essential part of programming in the Java language. Java threads are useful for many purposes, but because the Java language lacks an interface for non-blocking I/O (see the Resources section later in this article), threads are especially necessary in constructing communications intensive applications in Java. Typically one or more Java threads are constructed for each communications stream created by the Java program.
So what Java requires people to do in thousands of threads, I can do in one thread per processor with event driven non-blocking I/O. Hmmm... Sounds like Java is broken to me.
One area where both McKusick and Hubbard fervently agreed, however, was in their willingness to latch onto the momentum of their higher energy--and now higher profile--Linux colleagues. "My favorite quote about Linux and FreeBSD goes something like this: 'It's the pioneers that get the arrows in their backs, and it's the settlers that get the land,'" McKusick said.
"I'm more than happy to let Linux continue to be the open source pioneers."
Why I have the deepest respect for Mr. McKusick (he's a smart guy), I think he might have misinterpreted his own analogy:
BSD and the FSF pioneered Unix and open source respectively. Linux came and settled, by the millions.
The road to USB 2.0 won't be easy...
on
USB2 Specs Are In
·
· Score: 1
BTW - By the time USB 2.0 arrives, FireWire should up to 800 or 1600 Mbps. But that doesn't really matter. Even if the future USB 2.0 reaches today's FireWire throughput, it doesn't fix the USB protocol.
The fundamental problem with USB is that is was designed to be a CPU pig (thank you Intel). FireWire is the polar opposite and can do cool things like have your (FireWire) hard drive DMA a video stream directly from your camcorder.
Slashdot Mirror
Hmmm...
You prefer a byte.com self described opinion column over industry standard benchmarks...
No comment.
> It's not Linux thats wiping the floor, its TUX; the tiny in-kernel httpd that is designed for TRIVIAL matters. Putting the daemon inkernel is a glaring risk. It doesn't match the completeness of other userland servers like Apache.
First, TUX pushed the kernel to be fast in general. Somebody recently announced a user space web server called X15 on the linux-kernel mailing list that is more-or-less the same speed as TUX.Second, with respect to the comment about not "matching the completeness" of Apache. Both TUX and X15 support CGIs, and I know that TUX has a plug-in model (I wouldn't be surprised if there is a plug-in model in X15 either.) If there is a Apache module that you like, but you need a faster web server than Apache, maybe you should port the plug-in...
Finally, SpecWeb is a very real test of OS and web server performance. Something like 30% of it's output is driven by CGIs. It's not a trivial setup. Not only does it stress the networking stack, but it stresses the VM system and disk/block/vfs layer very hard too. (The working set of data on the web server can be larger than the amount of memory installed in the system.)
I know this sounds like flame bait, but I'm sick of the FreeBSD advocates claiming that they are faster than Linux when it comes to network servers. If that's true, where are the numbers to prove it?
I want to see SpecWeb results!
That's an Urban legand. When we switched from five to seven digits, people said the same thing.
Most, if not all telephone switches in the US today support ten digit dialing. Go ahead, try it. Dial:
1-<your-area-code>-<some-friend-in-your-a rea-code>
The PowerBook G3 (Pismo) has a 50Wh battery.
The Tranmeta based PictureBook has a 20Wh battery.
PowerBook advertised battery life: 5 hours
PictureBook advertised battery life: 2.5 - 5.5 hours (previously 1.5 - 2 hours with a PII-400).
Now does the "Trasmeta hype" seem more justified? It's now obvious why the most PC laptop manfactures are ramping up production of Transmeta based laptops.
Also, to answer why people would buy that Vaio:
The Sony Vaio PictureBook at 2.2 pounds is like a motorcycle.
The PowerBook on the other hand weighs in at 6.1 pounds and is like a SUV.
Now asking why somebody would buy a motorcycle when they can buy a SUV sounds silly, doesn't it?
Linux is king-of-the-hill in SpecWeb99 tests on One, Two, Four, and *8-way* systems. :-)
"Linux pthreads" is really just a library implemented on top of the Linux kernel clone() system call. The clone API scales just fine. The pthreads library on the other hand has "issues."
ROMs are slow. Ask any true Mac geek about ROM-in-RAM accelerators for traditional Mac OS (version 9 and below). Why? Modern SDRAM latency is less than 10ns. ROM latency is about 150ns. Need I say more?
Here is the URL: http://www.sony.co.jp /sd/ProductsPark/Consumer/PCOM/PCG-C1VJ/
4 32 bit floating point numbers
4 32 bit signed/unsigned integers
8 16 bit signed/unsigned integers
16 8 bit signed/unsigned integers
AltiVec provides extremely powerful SIMD instructions, and even special instructions targeted at graphics (convert between 16 bit and 32 bit pixels with one instruction).
AltiVec also provides a very cool vector permute unit/instruction.
Ouserhout didn't "turn around" his opinion on threads. He still believes that threads have their place in programming. He was simply trying to point out that threads aren't the panacea for all your programming ills, despite what industry hype would seem to suggest.
Yes, I would implement a client-server system with only one thread per processor. Keep in mind that each thread would be doing event driven I/O for potentially hundreds or thousands of connections.
The fact that the IBM guys are suggesting to change Linux to make up for deficiencies in the Java language seems extremely absurd to me.
davez
The key thing to remember out of the IBM article:
Threads are an essential part of programming in the Java language. Java threads are useful for many purposes, but because the Java language lacks an interface for non-blocking I/O (see the Resources section later in this article), threads are especially necessary in constructing communications intensive applications in Java. Typically one or more Java threads are constructed for each communications stream created by the Java program.
So what Java requires people to do in thousands of threads, I can do in one thread per processor with event driven non-blocking I/O. Hmmm... Sounds like Java is broken to me.
davez
Why I have the deepest respect for Mr. McKusick (he's a smart guy), I think he might have misinterpreted his own analogy:
BSD and the FSF pioneered Unix and open source respectively.
Linux came and settled, by the millions.
http://www.edtn.com/analog/c028.htm
BTW - By the time USB 2.0 arrives, FireWire should up to 800 or 1600 Mbps. But that doesn't really matter. Even if the future USB 2.0 reaches today's FireWire throughput, it doesn't fix the USB protocol.
The fundamental problem with USB is that is was designed to be a CPU pig (thank you Intel). FireWire is the polar opposite and can do cool things like have your (FireWire) hard drive DMA a video stream directly from your camcorder.
It's just about everything below the GUI.