The major microprocessor developers are all pursuing one of the following architecutreal paths:
SMT. Compaq is definitely doing this with the Alpha. There are rumors that IBM is working on it with their PowerPC line, although they may or may not have working prototypes.
VLIW: parallelism between instructions is discovered by the compiler and explicitly specified in the machine code. This is the way Intl and HP are going. [Don't be fooled by their new acronym EPIC, it's the same thing as VLIW. The only reason they don't want to say "VLIW" is that companies such as Multiflow that pursued VLIW in the '80s all died a flaming death when the technology proved unworkable, at least at that time.]
MCU: multiple simple processor cores in one package (possibly on one die, possibly as a multi-chip module). IBM has working prototypes of MCU PowerPC implementations. It's rumored that a research group in Compaq (but outside the Alpha microprocessor group) is developing an Alpha version.
The reason for pursuing these is really a matter of differences in underlying philosophy. SMT is based on the philosophy the throughput is more important than single-stream performance. VLIW is based on the belief that single-stream performance is most important. MCU is based on the notion that time-to-market is key.
Re:Finally, a chip you can *really* fry eggs on! :
on
Is SMT In Your Future?
·
· Score: 1
I work for Compaq on the Araña (aka EV8) project that this article is about.
Floating around our offices there's this comic somebody in the Alpha group drew years ago about the somewhat laughable concept of an Alpha-based portable. It shows the "Alpha notebook/backyard barbecue" crunching numbers and grilling steaks at the same time!
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.
Actually, I believe you're thinking of VLIW (aka EPIC) architectures. They need special compilers because parallelism is expressed in the instruction stream itself rather than discovered by the scheduling logic in the CPU. (Essentially, the compiler does some or all of the work of instruction scheduling.)
SMT does not have this problem. It needs support in the OS (to present OS-level processes/threads as CPU-level threads), not the compiler.
[BTW, I work for Compaq on the Araña (aka EV8) project that this article is about.]
No way, 21st century revision control: Vesta. (OK, so it hasn't made it out of Compaq's research division yet, but they're working on getting it released.)
in fact, our present, modern CPU's are really just elaborate abstractions of Turing machines.
Actually, it's worse than that. Since no buildable machine can have infinite storage (like a Turing machine's infinite tape), modern computers are really just finite state machines. Of course they have a very large number of potential states, but it is still finite (due to a finite number of bits).
I really don't understand why people put up with this kind of thing when there are perfectly good C/C++ garbage collectors out there. If you know you've got a memory leak, and you just can't fix it, it's downright criminal to ship a product without garbage collection.
...is that they're probably going to junk the units. They're probably totally unaware that there are people out there who would love to have one to hack. I'm sure some people would even pay a modest price for them, which would allow them to be less than a total loss for Virgin.
I don't suppose anybody out there has one of these and has gotten the letter described in the post? It might provide enough contact information for interested parties to contact Virgin and try to get one before it hits the scrap heap.
While maybe not exactly what you're looking for, Compaq's Alpha Development Group (you know, the people who make the highest performance microprocessors in the known universe) hire lots of interns and do all of their real work on Unix.
If you're not into microarchitecture or heavy EE work, there's still plenty of software development in their CAD group. There's also plenty of hardware-software boundary work in their verification group.
You can send your resume and any inquiries to:
Jaye Girouard, University Relations
Compaq Computer Corporation
Alpha Development Group
"Linux pthreads" is really just a library implemented on top of the Linux kernel clone() system call.
I'm pretty sure that any real thread library would need more support from the kernel than just clone(2) to work right. How're you supposed to implement an atomic test-and-set if the kernel can pre-empt you in the middle of it? With SMP, that becomes an even more difficult problem. Now I'm sure that the kernel must have its own mechanisms for mutual exclusion in order to make SMP work at all. Do you mean to suggest that there is no way for a user space program to do that kind of operation on Linux?
If so, then that's definitely a deficiency.
Like I said though, I don't know, so maybe somebody who does could speak up (hint hint).
I've also heard from a colleague that the Linux pthreads implementation was having some problems under SMP (like mutexes not really mutually excluding). Since multi-threading is most useful when you have multiple processors, this seems like a serious deficiency. Maybe it's all better in 2.4, I haven't checked. Does anybody know?
Why is it that "my" community is always there when it comes to ruining legitimate businesses? As soon as some company comes up with a neat device and accompanying businessmodel (I-Opener, Cuecat), there's a whole bunch of geeks that are ready to ruin the company by finding all kinds of little loopholes in some law.
It's not that any community is out to ruin anyone else, it's just an emergent property of connecting the whole word with a sufficiently powerful communication medium. You've got all these smart, curious people out there. For any thing that is out, there available to be had by the masses, some of them are going to tinker with it, diassemble it, and put it to unanticipated uses. Thanks to the Internet, they can help each other figure out how something works and what other neat things can be done with it. Just as "given enough eyes all bugs are shallow," given the whole world, somebody is going to figure out how your device works and tell others.
It's just a fact of life in the Internet age that, sadly, some businesses fail to take into account. Whining about the fate of companies with flawed business models and those same companies trying to get everyone to stop tinkering will be about as effective as shouting at the wind.
I hope your claimed lack of preparedness is ironic.
I saw him speak at the Geek Pride festival in Boston back in April. An appropriate title would have been "CmdrTaco babbles incoherently". There was clearly little to no preparation involved. It was quite slow at first, but he did manage to engage the audience in some discussion after a bit, and then it actually got interesting.
...is the same as it always has been: broadening your scope. The more different kinds of stuff you know, the more adaptable you are, and in turn the more valuable you are to employers.
I don't write compilers for a living, but I know how to build a parser for a context-free grammar, and I know a few things about object code optimization. Why? Because I wrote an optimizing compiler as a class project in college. Since I work in a group that makes microprocessors, it's really handy to understand how machine code gets generated.
I don't do VLSI layout, but I work with people who do. The fact that I did some in college makes it easier for me to understand what they do, what they need, and what they're talking about.
When I first started at my current job, all my coding was in imperative languages (almost all C/C++). Two years later, I started working with a system that uses a functional language. This was no problem for me because I had been exposed to and used functional languages in college.
I don't get paid to do 3D graphics, but I understand the math, I know how ray-tracing works, and I can use OpenGL. Sometimes I think about switching careers to that industry, and if I ever decide to, that knowledge will be very helpful.
If all your knowledge come from expereince, then you only know what you've done. How depressing would that be?
A digital copy of a work (DVD, and even MP3 for the RIAA) is an exact copy. Quality is not degraded through the copying process.
Maybe you haven't heard, but MP3 is what's called a lossy compression format. That's why they're so small. (This is the same reason why JPEGs are smaller than GIFs.) Yes, most of the time you won't notice, but I have several tracks that despite tweaking of bitrates and trying different encoders, don't come out sounding quite like the original once converted to an MP3.
But now... Have any of you watched a video recording recently? I taped a TV program just last night (hope the MPAA doesn't find out about it!) and watched it this morning; the quality compared to even regular TV, much less DVDs, was terrible. Even if the feeds are coming in through digital means, VHS tapes are a horrible representation of the original.
I'd bet that they're more concerned about the digital recording devices like TiVo and the set-top boxes you can get with services like Dish Network. Those can get you very high quality digital capture, and when it's from a digital source, the results are excellent. A computer savvy user could easily set up such a system to capture a bunch of programming, and later spool it off to a machine that compresses it with DivX and uploads it or re-formats it to be burned onto VCDs. They have good reason to be scared about that (although they won't be able to stop it).
Store the stuff on a server you run if you actually believe in the spread of DeCSS.
How is this supposed to make any difference? The MPAA can just threaten your upstream provider and get them to cut you off. An individuals with web server generally doesn't matter enough to an ISP to keep them from getting you cut off.
I'm really tired of seeing news items of the form "[closed-source application] released for Linux," when it's just an x86 binary. The "x86 == Linux" disease is, IMHO, at least as bad as the "RedHat == Linux" disease, if not worse. Linux is not just about x86 (even though that's where it started).
I'm not saying tha AOL or anybody else is obligated to produce a PPC, Alpha, etc. binary but they could at least make it clear that their release for Linux on a specific CPU architecture, which is not the same thing as "for Linux".
Even if the people releasing the software can't get it right, I'd think that/. would. I mean, just today there's been an article about Linux on a non-x86 processor. Doesn't having applications on devices such as this matter just as much as having them on x86 Linux? We shouldn't downplay their importance by ignoring them with our language.
The article suggests that centrigufal force is just as effective. Have a spinning section of your station that pproximates 1g and spend most of your time in there. You'd probably be more comfortable that way anyway.
This result doesn't really surprise me much. We're adapted to the environment we evolved in.
Now I'm all for opening driver sources, but if it came down between the choice of more driver support for Linux and Open Source code, I'd be torn.
Don't be torn. This isn't an either-or kind of thing. Closed source drivers means poor support.
To me personally, the biggest reason why closeed source drivers are bad is that they're almost universally x86 only. The leaves those of us on other CPU architectures (I run Linux on PPC and Alpha at home, and Alpha at work) out in the cold. The really sad thing is that vendors wouldn't even have to do the porting themselves if they'd just release the source. There are plenty of us out here who want to put cool hardware in our machines and have the skills to make the drivers work. Unfortunately, it's very hard to quantify the effect this would have on sales, which makes it hard to justify to the suits.
Another reason why closed source drivers means bad support is kernel specificity. Sure, the driver may be certified to work just great with that kernel RedHat 6.2 or SuSe 6.4 installed for you. But what if you're working out on the development branch? You're SOL, that's what.
And of course there's all the other reasons everybody here knows by heart (faster bug fixes, lower code maintenance costs, etc.).
And the whole "somebody's gonna steal our tech" argument is usually bogus. Unless we're talking about something very high-end, the competition for the consumer's dollars will be very fierce. If you have an innovation over your competitor, they'll one-up you in six months time. (For example, look at the pace of the 3D accelerator market ever since it's become mainstream.) In other words, by the time they could reverse engineer whatever it is you're doing, they could have just as well worked out their own newer, better tech. Reverse engineering your competitors in a commodity market is almost never worth it.
Don't forget there's already a processor on the board!
Comparing a complete system with a bare x86 motherboard is not really what I'd call fair.
Even if you include the price of processor and memory, you come out way ahead with an x86 solution. Again, I'll use the example of the system I'm building right now:
Chalice CATS board (including SA 1110 processor and 32MB RAM): $527 total
Comparable bits of my dual-processor system: $400 total
I looked at these a few months ago. If you check the only distrubtor Chalice mentions, these things come in at 350 pounds bare which works out to about $527 for us yanks. Compared to x86 motherboards, that's an awful lot. (OK, it's not completely bare, it has a 32 Meg DIMM and comes with a CD. That doesn't make it worth it.)
I'd love to build a StrongARM machine, but that's more than 4 times what I just paid for a new dual-processor x86 motherboard (the Abit BP6). I couldn't justify the expense.
No one [...] will enter a field where the prospects of earning a decent living are substantially lower than in other fields.
Being able to earn a living is not necessarily dependent upon the ability to own IP. At the risk of repeating what others have said over and over, it's all about services. Look at sourceXchange, CoSource, and the other similar sites popping up these days. They work precisely because the value is in the ability to code, not the the produced software. Besides, most people who produce IP never see big returns from their work anyway. They exchange their IP production services for a steady paycheck.
The basic point behind all of this is that the value of the IP being copied outweighs the cost of copying it. That balance is only going to tip further as bandwidth increases and storage gets cheaper. Interests that make money selling IP will continue to put in technical countermeasures and legal deterrents, but they're fighting a losing battle. In an economic sense, information really does want to be free.
So SourceForge now has compile farm resources for x86 and IA-64. What about the other architectures? Where's the PPC compile farm, the ARM compile farm, the Alpha and MIPS compile farms?
There's got to be a demand for these among open source developers. Most people don't have that many architectures that they can compile and test on, but most people would like their code to work on as many platforms as possible.
Slashdot Mirror
The major microprocessor developers are all pursuing one of the following architecutreal paths:
The reason for pursuing these is really a matter of differences in underlying philosophy. SMT is based on the philosophy the throughput is more important than single-stream performance. VLIW is based on the belief that single-stream performance is most important. MCU is based on the notion that time-to-market is key.
I work for Compaq on the Araña (aka EV8) project that this article is about.
Floating around our offices there's this comic somebody in the Alpha group drew years ago about the somewhat laughable concept of an Alpha-based portable. It shows the "Alpha notebook/backyard barbecue" crunching numbers and grilling steaks at the same time!
[There actually was an Alpha notebook back in '96, but AFAIK there wasn't much demand for it and it died fairly quickly. Who would want to run VMS on a laptop anyway?]
Actually, I believe you're thinking of VLIW (aka EPIC) architectures. They need special compilers because parallelism is expressed in the instruction stream itself rather than discovered by the scheduling logic in the CPU. (Essentially, the compiler does some or all of the work of instruction scheduling.)
SMT does not have this problem. It needs support in the OS (to present OS-level processes/threads as CPU-level threads), not the compiler.
[BTW, I work for Compaq on the Araña (aka EV8) project that this article is about.]
No way, 21st century revision control: Vesta. (OK, so it hasn't made it out of Compaq's research division yet, but they're working on getting it released.)
Actually, it's worse than that. Since no buildable machine can have infinite storage (like a Turing machine's infinite tape), modern computers are really just finite state machines. Of course they have a very large number of potential states, but it is still finite (due to a finite number of bits).
The Compaq iPaq Pocket PC, which can run Linux and X, can be hooked up to an expansion sleeve with a CardBus slot. You can then stick in any old 802.11 card. I've seen it working, and it rocks.
[I do work for Compaq, but I'm a hacker, not a marketroid.]
I really don't understand why people put up with this kind of thing when there are perfectly good C/C++ garbage collectors out there. If you know you've got a memory leak, and you just can't fix it, it's downright criminal to ship a product without garbage collection.
I don't suppose anybody out there has one of these and has gotten the letter described in the post? It might provide enough contact information for interested parties to contact Virgin and try to get one before it hits the scrap heap.
CPU Scorecard doesn't include Alpha or "other high-end SMP-capable processors", so I wouldn't pay too much attention to whatever they happen to rank at the top of their little list.
While maybe not exactly what you're looking for, Compaq's Alpha Development Group (you know, the people who make the highest performance microprocessors in the known universe) hire lots of interns and do all of their real work on Unix.
If you're not into microarchitecture or heavy EE work, there's still plenty of software development in their CAD group. There's also plenty of hardware-software boundary work in their verification group.
You can send your resume and any inquiries to:
[Disclaimer: I work for ADG.]
I'm pretty sure that any real thread library would need more support from the kernel than just clone(2) to work right. How're you supposed to implement an atomic test-and-set if the kernel can pre-empt you in the middle of it? With SMP, that becomes an even more difficult problem. Now I'm sure that the kernel must have its own mechanisms for mutual exclusion in order to make SMP work at all. Do you mean to suggest that there is no way for a user space program to do that kind of operation on Linux?
If so, then that's definitely a deficiency.
Like I said though, I don't know, so maybe somebody who does could speak up (hint hint).
I've also heard from a colleague that the Linux pthreads implementation was having some problems under SMP (like mutexes not really mutually excluding). Since multi-threading is most useful when you have multiple processors, this seems like a serious deficiency. Maybe it's all better in 2.4, I haven't checked. Does anybody know?
That probably makes it the fastest Linux machine in the known universe.
Well, at least at no-ops. :-)
It's not that any community is out to ruin anyone else, it's just an emergent property of connecting the whole word with a sufficiently powerful communication medium. You've got all these smart, curious people out there. For any thing that is out, there available to be had by the masses, some of them are going to tinker with it, diassemble it, and put it to unanticipated uses. Thanks to the Internet, they can help each other figure out how something works and what other neat things can be done with it. Just as "given enough eyes all bugs are shallow," given the whole world, somebody is going to figure out how your device works and tell others.
It's just a fact of life in the Internet age that, sadly, some businesses fail to take into account. Whining about the fate of companies with flawed business models and those same companies trying to get everyone to stop tinkering will be about as effective as shouting at the wind.
I saw him speak at the Geek Pride festival in Boston back in April. An appropriate title would have been "CmdrTaco babbles incoherently". There was clearly little to no preparation involved. It was quite slow at first, but he did manage to engage the audience in some discussion after a bit, and then it actually got interesting.
If all your knowledge come from expereince, then you only know what you've done. How depressing would that be?
Maybe you haven't heard, but MP3 is what's called a lossy compression format. That's why they're so small. (This is the same reason why JPEGs are smaller than GIFs.) Yes, most of the time you won't notice, but I have several tracks that despite tweaking of bitrates and trying different encoders, don't come out sounding quite like the original once converted to an MP3.
I'd bet that they're more concerned about the digital recording devices like TiVo and the set-top boxes you can get with services like Dish Network. Those can get you very high quality digital capture, and when it's from a digital source, the results are excellent. A computer savvy user could easily set up such a system to capture a bunch of programming, and later spool it off to a machine that compresses it with DivX and uploads it or re-formats it to be burned onto VCDs. They have good reason to be scared about that (although they won't be able to stop it).
How is this supposed to make any difference? The MPAA can just threaten your upstream provider and get them to cut you off. An individuals with web server generally doesn't matter enough to an ISP to keep them from getting you cut off.
I'm really tired of seeing news items of the form "[closed-source application] released for Linux," when it's just an x86 binary. The "x86 == Linux" disease is, IMHO, at least as bad as the "RedHat == Linux" disease, if not worse. Linux is not just about x86 (even though that's where it started).
I'm not saying tha AOL or anybody else is obligated to produce a PPC, Alpha, etc. binary but they could at least make it clear that their release for Linux on a specific CPU architecture, which is not the same thing as "for Linux".
Even if the people releasing the software can't get it right, I'd think that /. would. I mean, just today there's been an article about Linux on a non-x86 processor. Doesn't having applications on devices such as this matter just as much as having them on x86 Linux? We shouldn't downplay their importance by ignoring them with our language.
The article suggests that centrigufal force is just as effective. Have a spinning section of your station that pproximates 1g and spend most of your time in there. You'd probably be more comfortable that way anyway.
This result doesn't really surprise me much. We're adapted to the environment we evolved in.
Don't be torn. This isn't an either-or kind of thing. Closed source drivers means poor support.
To me personally, the biggest reason why closeed source drivers are bad is that they're almost universally x86 only. The leaves those of us on other CPU architectures (I run Linux on PPC and Alpha at home, and Alpha at work) out in the cold. The really sad thing is that vendors wouldn't even have to do the porting themselves if they'd just release the source. There are plenty of us out here who want to put cool hardware in our machines and have the skills to make the drivers work. Unfortunately, it's very hard to quantify the effect this would have on sales, which makes it hard to justify to the suits.
Another reason why closed source drivers means bad support is kernel specificity. Sure, the driver may be certified to work just great with that kernel RedHat 6.2 or SuSe 6.4 installed for you. But what if you're working out on the development branch? You're SOL, that's what.
And of course there's all the other reasons everybody here knows by heart (faster bug fixes, lower code maintenance costs, etc.).
And the whole "somebody's gonna steal our tech" argument is usually bogus. Unless we're talking about something very high-end, the competition for the consumer's dollars will be very fierce. If you have an innovation over your competitor, they'll one-up you in six months time. (For example, look at the pace of the 3D accelerator market ever since it's become mainstream.) In other words, by the time they could reverse engineer whatever it is you're doing, they could have just as well worked out their own newer, better tech. Reverse engineering your competitors in a commodity market is almost never worth it.
Even if you include the price of processor and memory, you come out way ahead with an x86 solution. Again, I'll use the example of the system I'm building right now:
I looked at these a few months ago. If you check the only distrubtor Chalice mentions, these things come in at 350 pounds bare which works out to about $527 for us yanks. Compared to x86 motherboards, that's an awful lot. (OK, it's not completely bare, it has a 32 Meg DIMM and comes with a CD. That doesn't make it worth it.)
I'd love to build a StrongARM machine, but that's more than 4 times what I just paid for a new dual-processor x86 motherboard (the Abit BP6). I couldn't justify the expense.
Being able to earn a living is not necessarily dependent upon the ability to own IP. At the risk of repeating what others have said over and over, it's all about services. Look at sourceXchange, CoSource, and the other similar sites popping up these days. They work precisely because the value is in the ability to code, not the the produced software. Besides, most people who produce IP never see big returns from their work anyway. They exchange their IP production services for a steady paycheck.
The basic point behind all of this is that the value of the IP being copied outweighs the cost of copying it. That balance is only going to tip further as bandwidth increases and storage gets cheaper. Interests that make money selling IP will continue to put in technical countermeasures and legal deterrents, but they're fighting a losing battle. In an economic sense, information really does want to be free.
So SourceForge now has compile farm resources for x86 and IA-64. What about the other architectures? Where's the PPC compile farm, the ARM compile farm, the Alpha and MIPS compile farms?
There's got to be a demand for these among open source developers. Most people don't have that many architectures that they can compile and test on, but most people would like their code to work on as many platforms as possible.