You may be right. But when I'm writing music software I would like to be able to guarantee the latencies for the user. One glitch is too many! Windows is not architected for glitch-free low-latency playback (mind you, neither is the MacOS!) Your playback could suddenly go to pot if, say, someone opened a network port on your machine. Not to mention the problems if the disk thrashes. I guess for synthesis this is acceptable, but for processing (i.e. take a LIVE audio input and process it; maybe save it to disk) none of these OSes are up to the job.
Except, perhaps, BeOS... but I have only "heard good things" about BeOS, and never actually tried it out.
Multiplexing the row and column addresses over an 8-bit bus. Sure it makes board design easier, but it means your best-effort latency with 800MHz RDRAMs, is 5ns, IGNORING THE TIME IT TAKES TO PRECHARGE THE ROW. That's 50 cycles on a GHz CPU, just to get a command through the RDRAM architecture. The actual latency of DRAM is of course worse than this, but the RDRAM architecture adds this latency just to save pins.
I'm sure the engineers designing the Alpha EV7 are perfectly well aware of the limitations of Rambus technology. Probably more so than I am.
Windows is simply unacceptable. The other post here about DirectX is quite misinformed. MacOS gives unbelievably better latency than Windows. Compare ReBirth for Windows/DirectX with >20ms latency (>100ms on NT) to ReBirth for Mac with
MacOS is reasonably low-latency, but it's going in the wrong direction. Unices (love em or hate em) are again not designed for real-time work. The RT Linux stuff is promising, but apparently it's hard to dynamically link stuff into the real-time section, and you can't even use the FPU without jumping through some hoops.
BeOS on the other hand is designed from the ground up for low-latency high-speed access to multimedia hardware. BeOS is asking for this sort of software, and it's cheap (if you're paying $500 for a soft synth, another $50 for the OS to run it on isn't too big a deal).
The absolute best solution, of course, would be to not use a proprietory OS. But that's a way off yet;)
I'll wait for independent benchmark tests on the P4, thanks. The only way you can saturate a 64-bit, 400MHz bus using RDRAM is to have 4 chips running pre-requested consecutive accesses, and even then the bus load will be more like 83% because of bank switches. This is *not* a real benchmark.
RDRAM has a fundamental design philosophy that prevents it ever achieving the low latency or high bandwidth in practice that its spec sheets suggest. Improving the CPU/RDRAM interface will not change this simple fact. Benchmarks be damned... just look at the datasheets.
RDRAM is technology that was good in the mid 90s but which has been surpassed by DDR SRAM. Making DDR SRAM scale is a far simpler problem than making RDRAM efficient. People tend to solve the simpler problems first.
What, do you work for Rambus?;) In this case (but not all cases!) the Slashdot mentality is pretty much on the money. Forget the fact that patents suck, or that Intel is "evil" - just look at RDRAM performance in real systems.
I've been using Rambus parts for years (N64, now PS2) and the performance just isn't that great. Performance is what people like, not cool designs or easy board layout. The theoretical performance isn't even that important - it's the massive complexity of the RDRAM controller on the FSB which drags the actual numbers down. Add to that the fact that RDRAM bandwidth is only 1/3 of theoretical bandwidth even in the best case, unless you have multiple channels open simultaneously. Great for multiproc servers, perhaps, but lousy for singleproc desktop machines.
So, I'd be interested to know, why do you think future memory will be more like Rambus and less like SRAM?
Object dynamism is unnecessary. Mostly. Certainly, its prevalent use in CLOS and Smalltalk makes those languages slow. C++ is fast precisely because it doesn't have object dynamism, past virtual functions.
This thing about "your CLOS implementation" is rubbish. There are only about five, and we have the best. It still sucks.
Converting a large project to another language is not something to be done lightly. I certainly wouldn't spend months switching to another slow interpreted language.
No, I hate Emacs too;)
I might not be spending 40 hours weeks writing C++ now, but I have in the past (thank God). Ambiguous nonsense is hardly a good description. The language is complex enough to have some abiguity for the naive - every ambiguity is actually not ambiguous, of course, or else programs wouldn't compile. That's nothing compared to the ambiguity of calling a CLOS method.
Still, if you think interpreted OO languages are the future, don't let me put you off.
Yeah, but in that case they sued the band Judas Priest. Maybe the record companies should be held liable for trafficking (er... racketeering) in records which "everybody knows" incite violence, hatred towards women, etc. etc.
Yup, let's solve the music issue later. Oops. Too late. A bunch of idiots have already gone all out over the internet saying that they have a right to copy music and that no-one can stop them. Now the people they dared to stop them are doing so. The result? No freedom on the internet.
Writing a LISP compiler in LISP is a joy! The benefits are less clear for, say, a C++ compiler. LISP definitely makes the syntax parsing easier. But writing an industry-strength compiler is a different matter. You really want to be using objects, and CLOS is very slow compared with C++. The listy aspects are only a small part of a full compiler, but a large part of a mini-compiler, IYSWIM. Part of our project is indeed a compiler, and the main problem with that is its speed - not good. But if you were doing a CS course and one of the assignments was to write a mini-compiler, then LISP would be a good choice of implementation language.
We use LISP macros everywhere, sure. That's one of my complaints about the language. Everyone on a team can write their own mini embedded language, using macros, which means everyone else's code is virtually incomprehensible to you - and vice versa. But macros is definitely a powerful feature, and I was attracted to LISP initially because of that power.
Anyway, my complaints about LISP are not entirely serious. Horses for courses, etc. etc. It's just when you use a language everyday its flaws become oh-so-apparent. And you like to moan! But I'm not saying that LISP is without its uses: emacs being a case in point.
You become an advocate of a language by recognizing its power? Well, to compare with that, I use LISP for 40 hours a week professionally. And in doing *that* I've come to the conclusion that it sucks. At least, compared to a good OO language like C++ or Smalltalk. On the other hand, it *is* better than Perl - it just made me laugh that you compare two shitty languages and say one's better than the other. They're both shitty!;)
Re:Software is just software
on
Men of Zeal
·
· Score: 1
We used to have a TV program for kids in the UK called "Why Don't You?" The theme tune went, "Why don't you turn off the TV and do something more interesting instead."
Katz, you say that traditional media such as newspapers offer "few choices and little control".
They are not "interactive".
A newspaper is too large for most people to read it in its entireity. So what do we do? We choose which stories look interesting or important and we use our hands to control the turning of the pages to get to those articles. If that's not "interactive" (in the Katz sense, not in the dictionary sense) then I don't know what is!
Slashdot Mirror
Except, perhaps, BeOS ... but I have only "heard good things" about BeOS, and never actually tried it out.
No you can't. Read the freaking spec sheets for a real RDRAM. Look at the CAS-to-CAS time for a single bank and do the sums yourself.
I'm sure the engineers designing the Alpha EV7 are perfectly well aware of the limitations of Rambus technology. Probably more so than I am.
Windows is simply unacceptable. The other post here about DirectX is quite misinformed. MacOS gives unbelievably better latency than Windows. Compare ReBirth for Windows/DirectX with >20ms latency (>100ms on NT) to ReBirth for Mac with MacOS is reasonably low-latency, but it's going in the wrong direction. Unices (love em or hate em) are again not designed for real-time work. The RT Linux stuff is promising, but apparently it's hard to dynamically link stuff into the real-time section, and you can't even use the FPU without jumping through some hoops.
BeOS on the other hand is designed from the ground up for low-latency high-speed access to multimedia hardware. BeOS is asking for this sort of software, and it's cheap (if you're paying $500 for a soft synth, another $50 for the OS to run it on isn't too big a deal).
The absolute best solution, of course, would be to not use a proprietory OS. But that's a way off yet ;)
So, you wanna help me write this?
I'll wait for independent benchmark tests on the P4, thanks. The only way you can saturate a 64-bit, 400MHz bus using RDRAM is to have 4 chips running pre-requested consecutive accesses, and even then the bus load will be more like 83% because of bank switches. This is *not* a real benchmark.
RDRAM is technology that was good in the mid 90s but which has been surpassed by DDR SRAM. Making DDR SRAM scale is a far simpler problem than making RDRAM efficient. People tend to solve the simpler problems first.
I've been using Rambus parts for years (N64, now PS2) and the performance just isn't that great. Performance is what people like, not cool designs or easy board layout. The theoretical performance isn't even that important - it's the massive complexity of the RDRAM controller on the FSB which drags the actual numbers down. Add to that the fact that RDRAM bandwidth is only 1/3 of theoretical bandwidth even in the best case, unless you have multiple channels open simultaneously. Great for multiproc servers, perhaps, but lousy for singleproc desktop machines.
So, I'd be interested to know, why do you think future memory will be more like Rambus and less like SRAM?
This thing about "your CLOS implementation" is rubbish. There are only about five, and we have the best. It still sucks.
Converting a large project to another language is not something to be done lightly. I certainly wouldn't spend months switching to another slow interpreted language.
No, I hate Emacs too ;)
I might not be spending 40 hours weeks writing C++ now, but I have in the past (thank God). Ambiguous nonsense is hardly a good description. The language is complex enough to have some abiguity for the naive - every ambiguity is actually not ambiguous, of course, or else programs wouldn't compile. That's nothing compared to the ambiguity of calling a CLOS method.
Still, if you think interpreted OO languages are the future, don't let me put you off.
You're in BIG TROUBLE, mister.
Yeah, but in that case they sued the band Judas Priest. Maybe the record companies should be held liable for trafficking (er ... racketeering) in records which "everybody knows" incite violence, hatred towards women, etc. etc.
Welcome to a world of our own making.
We use LISP macros everywhere, sure. That's one of my complaints about the language. Everyone on a team can write their own mini embedded language, using macros, which means everyone else's code is virtually incomprehensible to you - and vice versa. But macros is definitely a powerful feature, and I was attracted to LISP initially because of that power.
Anyway, my complaints about LISP are not entirely serious. Horses for courses, etc. etc. It's just when you use a language everyday its flaws become oh-so-apparent. And you like to moan! But I'm not saying that LISP is without its uses: emacs being a case in point.
But then, personally, I hate emacs too <g>
You become an advocate of a language by recognizing its power? Well, to compare with that, I use LISP for 40 hours a week professionally. And in doing *that* I've come to the conclusion that it sucks. At least, compared to a good OO language like C++ or Smalltalk. On the other hand, it *is* better than Perl - it just made me laugh that you compare two shitty languages and say one's better than the other. They're both shitty! ;)
Try to get beyond this 6th-grade philosophy.
Don't know what the TV show was about.
Outside? Which channel is that on?
Not without Philipa Forrester. Mmm. If I knew what hot grits were, I'd pour them down her pants.
ROFL!
Woah there! They smashed an iMac in Dawson's Creek? Which episode? I wanna get a copy! I hate my wife's iMac. It ate our wedding photos.
I'd like that too - then I wouldn't have to sit through all that Anime crap waiting for Tom & Jerry and Scooby Doo.
A newspaper is too large for most people to read it in its entireity. So what do we do? We choose which stories look interesting or important and we use our hands to control the turning of the pages to get to those articles. If that's not "interactive" (in the Katz sense, not in the dictionary sense) then I don't know what is!
It's easy to be mistaken, when you don't read the rules. ANY language is allowed. It says so EXPLICITLY.
Except for machines with the latest DevStudio beta installed. Duh!
Shows how shitty LISP is that you consider its nearest rival to be Perl.
God, Lexx really sucks.