I worked at Interact, Inc. the largest supplier of teleco grade VIP (Voice and Information Processing) platforms for a couple years. When I initially started there we used primarily SCO Unix on x86 hardware with Aculab and Dialogic telephony cards. I and a few others evangelized Linux profusely--along with porting to C++ from straight C. Eventually, the hardware vendors started to release drivers on Linux circa 1999. Around late 2000 the core telephony engine was ported over to C++ on Linux and they've been extremely happy about that decision ever since.
I remember meeting with Dialogic representatives once and they questioned our plans for Windows platforms and why we did use it, and we all got to just laugh and laugh. Our systems never have the option of rebooting.
It's not like Bush actually ever does real work! It's on perma-vacation a couple hours away from me.
Re:They're having clock speed issues with Hammers.
on
AMD Delays Hammer
·
· Score: 1
Exactly... "Engineering samples" they haven't been able to stably clock up, which is why the release of the "production" units is being delayed until they rectify this. Don't get me wrong, they're making progress, and the 800MHz were a batch from the first go round, but this is why they're delaying the release of the "productions units." I'm talking about the unlocked "engineering samples" in AMD's lab as not clocking up, not what hardware sites get to look at. The 800MHz limit was based on what AMD's lab could stably clock their "engineering samples" to. I have faith though, Hammers will own.
They're having clock speed issues with Hammers...
on
AMD Delays Hammer
·
· Score: 5, Interesting
You ever notice how all the Hammers are clock speed locked at 800MHz? Yea, there's a reason for that. They're having problems cranking the clock speed up. For 800MHz they're fast as hell, beating P4 with twice the frequency, but they're not gonna release them until they clock faster than current Athlons so they're trying different types of transitors and what not.
How the hell do I know that??? Look where I live, take a guess...The birds outside my window know things.
And uhm, I think the default behavior for hitting "return" should be to preview. Going to hit the apostrophe key and hitting return instead and getting that posted... That is teh suck.
He said the first dual RISC 1U. He said RISC. Athlon is definitely CISC. BUT, who can argue that that dual 1Ghz G4s could even come close to touching the number crunching umph of a a dual 1.6 GHz Athlon? Even with the G4's vector capabilities, I still think the Athlon will trounce it. Not to mention higher density ECC.
The real question I guess, is how good is the available development software for OS X at expoiting the vector capabilities of the G4? Does it generate code that runs as fast as Intel Compiler optimized code on Athlons/P4s?
My DVD Decoder was sharing an IRQ and would stutter every few minutes. Sigma Designs tech support had me disable ACPI in WinXP and it worked after that, but it was kind of a pain having to isolate it's IRQ. I thought it was just a drivers glitch. You should have to disable ACPI in the BIOS though.
At my school, both Software Engineering is indeed part of the Electrical Engineering department; those are who you are really comparing.
Computer Science is different. Computer Science is more like: compilers, OSes, the Halting Problem, P and NP, etc. We look at asymptotic bounds, amortized algorithmic performance, etc.
Of course, the majority of lessons I learned in college were outside of class. I enjoyed my histories courses more than most of my Computer Science courses because it was something I knew so little of before hand... and they were easier, but whatever.
Ever heard of cruise missles? Have we had a problem with them? There are failsafes, and a hellfire missle isn't going to sink a Destroyer. They can just turn on their Phalanx anti-missle gun.
Is there a way to just disable IIS? I think that'd be the best solution.
I got a multi-homed box in a colo that's hitting hit with multiple attacks/second. No performance biggy, but I'd like to start neutralizing this. My log files are getting big. Guess I'll make a PHP script to keep track of this stuff.
The only good points about it are low power consumption/heat production, it looks cool, and its compactness. As for price/performance, you would smack that all around with a Athlon cluster that cost the same price.
It better have some badass compilers that will vectorize code for AltiVec included.
Still, having a little 16-node cluster sitting beside your desk would be neat.
Ryan Earl
Student of Computer Science
University of Texas
Hrm... I read the paper again... It wasn't the one with the simulations. I can't find that one. We had to read a series of papers, I thought it was that one. I can't seem to find the one that compares those three specific archs.
Ryan Earl
Student of Computer Science
University of Texas
And here's his homepage with other articles you should find interesting. He's the hauss; one the best professor I've ever had the pleasure of taking.
The architecture is called CMT = Chip MultiProcessor.
Ryan Earl
Student of Computer Science
University of Texas
Unfortunately, I don't have the paper anymore and it has been over a year since I read it. That recount is what I remember. There was a lot more, it was a most interesting paper. I held onto it for a long time, but misplaced it in a move 6 months ago. I'll email Prof. Berger and see if I can get another copy to post.
Ryan Earl
Student of Computer Science
University of Texas
I read a very good paper while taking Systems Architecture at UT by Dr. Berger that he wrote while he was at Wisconsin. They simulated three different billion transistor architectures:
Massively Parallel/Pipelined ala today's processor
SMT
Multiple simple core on-die
The MSC (forgot the real abreviation, but that's what I'm going to call it) architecture had 4 simple, identical cores. Each core was about somewhere between a Pentium and a K6 in terms of complexity--lean on scheduling logic, heavy on executive hardware--each with an independent, decent sized L1 cache. The MSC chip had a large on-die L2 cache quad-ported or oct-ported that all processing cores could access quickly and simultaneously, and a fat L3 cache to boot on-die. It also contained some special context caching mechanism.
The cores are actually able to execute in different contexts as well, not just within the same context as with SMT. This opens up parallization across more than one process.
One of the more interesting problems in a billion transistor chip is the wire delay. With processes so small that a billion transistors can be put on a moderate sized die, the clock rate is so high that the wire delay from one side of the chip to another side can be over 100 clock cycles! So locality of information becomes extremely important. With multiple, simple processing cores, all the logic for the pipeline is close together. The data is readily available in L1 cache. The scheduling logic has been mostly handled outside the cores, all they have to do it crunch numbers within their context as fast as possible. They don't have to worry about sending/receiving signals from very far on the chip and the resultant delay, so everything is local and fast.
Additionally, it's the least complex chip to design. Only one processing core needs to be designed and tested since it's duplicated 4 times. The core is much simpler than other designs. The scheduling logic is all much simpler and easier to test. Most of the die space is devoted to localized caches and executive units, not scheduling logic.
In the benchmarks the SMT and MSC processors vastly outperformed a convential massively pipelined/parallel billion transistor processor. And the MSC performed an additional 20+% (on average) than the SMT processor.
On top of all that, to get the best performance from SMT processors you need very smart compilers that are able to find parallelizable code and generate the binary for such. With MSC this isn't a problem. It'll run multi-threaded code simultaneously, but it'll also run multiple processes or any combination of both processes and theads simultaneously without help from smart compilers.
Ryan Earl
Student of Computer Science
University of Texas
Maybe, but consider that the java compilers barely do any kind of optimizing has quite a bit to do with that. C/C++ compilers OTOH are extremely optimized, squeezing every bit of speed from the CPU. In a few years, when java compilers has matured, we'll be able to see if it really is a viable language.
It's not the compiler that needs to do the optimizing, it's the Virtual Machine. And nowadays, some VMs do optimizing and Just-in-Time compiling. In fact, it's been shown that an IBM VM that does JIT ends up being faster than compiling the Java to machine dependent code to behing with!
Ryan Earl
Student of Computer Science
University of Texas
Slashdot Mirror
I worked at Interact, Inc. the largest supplier of teleco grade VIP (Voice and Information Processing) platforms for a couple years. When I initially started there we used primarily SCO Unix on x86 hardware with Aculab and Dialogic telephony cards. I and a few others evangelized Linux profusely--along with porting to C++ from straight C. Eventually, the hardware vendors started to release drivers on Linux circa 1999. Around late 2000 the core telephony engine was ported over to C++ on Linux and they've been extremely happy about that decision ever since.
I remember meeting with Dialogic representatives once and they questioned our plans for Windows platforms and why we did use it, and we all got to just laugh and laugh. Our systems never have the option of rebooting.
It's not like Bush actually ever does real work! It's on perma-vacation a couple hours away from me.
Exactly... "Engineering samples" they haven't been able to stably clock up, which is why the release of the "production" units is being delayed until they rectify this. Don't get me wrong, they're making progress, and the 800MHz were a batch from the first go round, but this is why they're delaying the release of the "productions units." I'm talking about the unlocked "engineering samples" in AMD's lab as not clocking up, not what hardware sites get to look at. The 800MHz limit was based on what AMD's lab could stably clock their "engineering samples" to. I have faith though, Hammers will own.
You ever notice how all the Hammers are clock speed locked at 800MHz? Yea, there's a reason for that. They're having problems cranking the clock speed up. For 800MHz they're fast as hell, beating P4 with twice the frequency, but they're not gonna release them until they clock faster than current Athlons so they're trying different types of transitors and what not.
How the hell do I know that??? Look where I live, take a guess...The birds outside my window know things.
Their voice mailboxes were full!
And uhm, I think the default behavior for hitting "return" should be to preview. Going to hit the apostrophe key and hitting return instead and getting that posted... That is teh suck.
id, as in the opposite of ego.
He said the first dual RISC 1U. He said RISC. Athlon is definitely CISC. BUT, who can argue that that dual 1Ghz G4s could even come close to touching the number crunching umph of a a dual 1.6 GHz Athlon? Even with the G4's vector capabilities, I still think the Athlon will trounce it. Not to mention higher density ECC.
The real question I guess, is how good is the available development software for OS X at expoiting the vector capabilities of the G4? Does it generate code that runs as fast as Intel Compiler optimized code on Athlons/P4s?
My DVD Decoder was sharing an IRQ and would stutter every few minutes. Sigma Designs tech support had me disable ACPI in WinXP and it worked after that, but it was kind of a pain having to isolate it's IRQ. I thought it was just a drivers glitch. You should have to disable ACPI in the BIOS though.
You arguement is invalid. DDR isn't so cheap anymore. The only thing DDR has going for it--besides the Athlon--is super high density. 1GB modules.
I only wonder if you know the difference between a monolithic kernel and a microkernel.
At my school, both Software Engineering is indeed part of the Electrical Engineering department; those are who you are really comparing.
Computer Science is different. Computer Science is more like: compilers, OSes, the Halting Problem, P and NP, etc. We look at asymptotic bounds, amortized algorithmic performance, etc.
We look at a different class of problems.
Word...
Of course, the majority of lessons I learned in college were outside of class. I enjoyed my histories courses more than most of my Computer Science courses because it was something I knew so little of before hand... and they were easier, but whatever.
I'm sure we have tested ICBMs from more than those states.
Ever heard of cruise missles? Have we had a problem with them? There are failsafes, and a hellfire missle isn't going to sink a Destroyer. They can just turn on their Phalanx anti-missle gun.
Yea, so, I noticed on my 20 IP multi-homed linux server I was getting a lot of hits, so I here's my answer. Notice the confirmation log.
Now what's the W2K command to change the IP to 10.1.2.3?
As always, it's being improved, but I've verified this script works on my server:
CodeRed Counter Script
The Logs, note Confirmation Log.
Now I just need to figure out that win32 command line to set the IP address to 10.1.2.3.
Is there a way to just disable IIS? I think that'd be the best solution.
I got a multi-homed box in a colo that's hitting hit with multiple attacks/second. No performance biggy, but I'd like to start neutralizing this. My log files are getting big. Guess I'll make a PHP script to keep track of this stuff.
The only good points about it are low power consumption/heat production, it looks cool, and its compactness. As for price/performance, you would smack that all around with a Athlon cluster that cost the same price.
It better have some badass compilers that will vectorize code for AltiVec included.
Still, having a little 16-node cluster sitting beside your desk would be neat.
Ryan Earl
Student of Computer Science
University of Texas
I like the noise, it keeps me sane.
Ryan Earl
Student of Computer Science
University of Texas
id software is in charge of making killer apps that neccessitate hardware upgrades. They do more to push consumer hardware than anyone else.
Ryan Earl
Student of Computer Science
University of Texas
Hrm... I read the paper again... It wasn't the one with the simulations. I can't find that one. We had to read a series of papers, I thought it was that one. I can't seem to find the one that compares those three specific archs.
Ryan Earl
Student of Computer Science
University of Texas
Doh, maybe if I spelled his damn name right. Dr. Burger not Dr. Berger.
"Billion Transistor Architectures" in PDF format.
And here's his homepage with other articles you should find interesting. He's the hauss; one the best professor I've ever had the pleasure of taking. The architecture is called CMT = Chip MultiProcessor.
Ryan Earl
Student of Computer Science
University of Texas
Unfortunately, I don't have the paper anymore and it has been over a year since I read it. That recount is what I remember. There was a lot more, it was a most interesting paper. I held onto it for a long time, but misplaced it in a move 6 months ago. I'll email Prof. Berger and see if I can get another copy to post.
Ryan Earl
Student of Computer Science
University of Texas
- Massively Parallel/Pipelined ala today's processor
- SMT
- Multiple simple core on-die
The MSC (forgot the real abreviation, but that's what I'm going to call it) architecture had 4 simple, identical cores. Each core was about somewhere between a Pentium and a K6 in terms of complexity--lean on scheduling logic, heavy on executive hardware--each with an independent, decent sized L1 cache. The MSC chip had a large on-die L2 cache quad-ported or oct-ported that all processing cores could access quickly and simultaneously, and a fat L3 cache to boot on-die. It also contained some special context caching mechanism.The cores are actually able to execute in different contexts as well, not just within the same context as with SMT. This opens up parallization across more than one process.
One of the more interesting problems in a billion transistor chip is the wire delay. With processes so small that a billion transistors can be put on a moderate sized die, the clock rate is so high that the wire delay from one side of the chip to another side can be over 100 clock cycles! So locality of information becomes extremely important. With multiple, simple processing cores, all the logic for the pipeline is close together. The data is readily available in L1 cache. The scheduling logic has been mostly handled outside the cores, all they have to do it crunch numbers within their context as fast as possible. They don't have to worry about sending/receiving signals from very far on the chip and the resultant delay, so everything is local and fast.
Additionally, it's the least complex chip to design. Only one processing core needs to be designed and tested since it's duplicated 4 times. The core is much simpler than other designs. The scheduling logic is all much simpler and easier to test. Most of the die space is devoted to localized caches and executive units, not scheduling logic.
In the benchmarks the SMT and MSC processors vastly outperformed a convential massively pipelined/parallel billion transistor processor. And the MSC performed an additional 20+% (on average) than the SMT processor.
On top of all that, to get the best performance from SMT processors you need very smart compilers that are able to find parallelizable code and generate the binary for such. With MSC this isn't a problem. It'll run multi-threaded code simultaneously, but it'll also run multiple processes or any combination of both processes and theads simultaneously without help from smart compilers.
Ryan Earl
Student of Computer Science
University of Texas
Maybe, but consider that the java compilers barely do any kind of optimizing has quite a bit to do with that. C/C++ compilers OTOH are extremely optimized, squeezing every bit of speed from the CPU. In a few years, when java compilers has matured, we'll be able to see if it really is a viable language. It's not the compiler that needs to do the optimizing, it's the Virtual Machine. And nowadays, some VMs do optimizing and Just-in-Time compiling. In fact, it's been shown that an IBM VM that does JIT ends up being faster than compiling the Java to machine dependent code to behing with!
Ryan Earl
Student of Computer Science
University of Texas