ah - you missed the obvious.... the label was on the plastic bottle, not the water..... it's the bottle that will go off (the water tastes the same.... it's all those little disolved bits of plastic bottle that will make it taste crappy)
people have been claiming 'patent-pending' for generations - it's sounds great to the unwashed masses.... but untill you read the patents themselves you can't make assumptions about their contents - I have no idea what this one is about but it could be any of: a novel way of hooking two chips together - something about how to handle cooling 2 hot chips on a little PCI card - a cool new way to handle interframe aliasing issues between seperately rendered frames - managing a texture cache across multiple frames etc etc
Anyway you get my point the 'patent pending' stuff is purely marketting speak to try and get you to buy the thing
> I think he was referring to automatic layout tools.
>Modern chips aren't designed in manual tools anymore.
actually I was talking about both. These days we still design high performance datapaths by hand, ram too and in particular the standard cells that our automatic synthesis and P&R use as building blocks
Design of these is done as a stack of 2d layers (metal on top with silicon at the bottom) It used to be that capacitance extraction was a pretty simple thing to do and not that important a reasonable approximation was all that was needed - these days extraction is much more difficult - it has to be done in 3D and includes all the interactions between a wire and allthe other objects that come close to it along its whole length - time was just did capacitance to the substrate and got a good estimate - now days you have to worry about edge effects and wire delays (distributed RC delays along the wire because they've got so thin they have appreciable resistance - this is the real reason copper is important - RC delays are smaller - not just that the wires can carry more current)
Certainly we don't have tools that take simple 3D effects into account while working (even many routers can't take the time to do full extractions while they run - they have to do approximations in order to work at all).
But what I was getting at was that we don't have layout tools or P&R tools that could be used to automatically place gates on top of each other (building stacks of silicon stuff rather than one set of layers of silicon stuff and lots of wires) there's so many sorts of analogish leakage issues that would kick in it would be a nighmare
I'm not an expert on quantum computing but is seems that those sorts of structures where electrons are contained by quantum effects rather wires, poly and diffusion may be more amenable to stacking since the quantum barriers could provide a sort of 'insulation' between devices in multiple dimensions that might not be possible in bulk silicon
>Furthermore, This "limit" would only limit single-processor designs..
well maybe not as much as you think - this article is from a process guy - he's talking about what can be made economically - basicly (at a first approx) you take the cost of running a wafer thru the fab then remove the number of bad dies and divide the wafer cost over the good ones - more good dies/wafer (aka 'yield') lower cost/die.
Double the size of the dies and the yield goes down - assume there are 50 bad spots on the wafer with 200 die/wafer you get roughly 75% yield, double the die size you get 100 die/wafer and only 50% yield - you have to charge 3 times as much for the 50 good 2x sized die as you charge for the 150 1x size die to pay for the wafer - this is a made up example intended to show the effect - in practice it's not a linear curve but something with a knee in it where yield drops suddenly.
On the other hand per-die packaging costs are more related to the number of pins which may be the same for 2 cpus vs one
Anyway - my point - putting 2 CPUs on a die without the process improvements that have been basicly driving Moore's law (at the chip level anyway) won't get you the same sorts of improvement that reducing feature size every 18 months or so.
Having said this there are other, better, reasons for putting multiple cpus/die that are starting to kick in (they have more to do with locality of signals withing dies at high clock speeds - you can't run a wire across a chip anymore - better to build multiple independant thingys each in its own corner) - however good SMP software is what's holding this back
I think the point of the original article is that it's going to be dificult to manufacture stuff below 0.1u using current technologies (resist and etching etc) - it's not that we can't build transistors that small in the lab - just that we probably can't do it in the factory - this is why it's a "process engineer" making the prediction, not a "physicist"
The basic idea is that you can't RELIABLY produce sub 100 atom wide structures and have them yield when your basic technology is dump some liquid on a surface to etch it, time how long it's on there, then wash it off - you have to get the solution at exactly the same concentration to every spot on the wafer at exactly the same time, then get it off all at the same time - so that some areas don't etch too much (or too little) - then you need to do the same thing several times for each layer.....
I wouldn't discount the process guys finding ways around these sorts of problems - there are an awfully large number of people out there who understand how to build stuff out of silicon - they don't know how to other (newish radical type) stuff as well as they understand silicon. I predict that silicon based FAB techniques will be around for a VERY long time - and densities WILL continue to increase.
What you might NOT see are traditional 2-D FET based stuff - I expect that what we may see in the future are 3 things:
better process control - down to less that the 100 atoms mentioned (but this wont be easy... the question is can it be done in volume and yield?)
new semiconductor devices - quantum dots/wells etc etc but still made in Si
3D fabrication - we're already moving away from the strict 2D world - the last chip I built had 4 metal layers and 1 poly, the next will have 6+1 - but the gates themselves are still pretty 2D - building devices in 3D is potentially a great way to get density, esp for memory - the CAD tools are certainly not up to it though
>> In addition, Linux does not support many of the modern operating >> system features that Windows NT 4.0 haspioneered such as >> asynchronous I/O...
>.... IIRC ext2 is asynchronous by default.
actually what I think they are getting at is the asynchronous I/O interface provided to users.... which NT of course didn't pioneer - they stole it from VMS - an almost 20 year old OS.....
Besides - this is so much FUD - Linux/Unix has threads which are functionally equivalent to signal based asynchronous I/O... and have an easier to program API.
People should realise that this is the CPU industry's season to sell vapor - you'll see a whole host of announcements of future chips, previews of new silicon etc etc 'Microprocessor Forum' is the conference where this sort of stuff happens.. and it starts today.
This isn't so much a bad thing Merced was announced in a similar manner MANY years ago - people should take anything you heer this week about the distant future (ie 2+ years) with a grain of salt - chips take a long time to bring to market and always change a lot during the process - remember they are announcing their goal - not new silicon that's sampling to customers - these are VERY different things.
let's see - this is a problem that only occurs on the fastest chips on some motherboards and in some cache configurations.
This sounds like a noise problem to me (whether it's the motherboard that's too noisy or the chip that's too sensitive to it or a combination of both is not obvious) I bet they can fix at least some of this by quieting down the Mobo environment.... but it may also point to the reason they're not deploying a direct K7 competitor (they can't they're running on the hairy edge at the moment) and instead are trying to put price pressure on AMD
I think he has a 4xOC3 ring pass thru his basement that would be ~600Mb/s - he doesn't use all of it it - shares it with the university down the road - but sounds like his claim that he has more bandwidth than.au through his basement is about right
BTW I still remember when e-mail and news to.au started up..... bandwidth was OK but latency was low.... (something to do with how long it took to air-mail those mag tapes full of UUCP spool files across the pacific:-)
I see alternate routes popping in - my 1.5 sec pings to/. are back to 100ms as abovenet kicks in different connections (DNS still going through europe though:-)
Of course when nuclear war hits it will take at least 3 hours to fix....
1 198.182.167.17 (198.182.167.17) 0.628 ms 0.564 ms 0.532 ms 2 adsl-63-194-218-254.dsl.snfc21.pacbell.net (63.194.218.254) 26.688 ms 29.433 ms 15.868 ms 3 core1-fe4-1-0.snfc21.pbi.net (206.171.134.209) 13.394 ms 13.701 ms 15.957 ms 4 gsr1-g1-0.snfc21.pbi.net (209.232.130.20) 16.098 ms 13.846 ms 15.215 ms 5 sfra1sr3-so-1-1-1-0.ca.us.prserv.net (165.87.161.74) 16.676 ms 16.208 ms 15.202 ms 6 sfra1sr2-11-0-0.ca.us.prserv.net (165.87.13.17) 16.684 ms 16.286 ms 15.226 ms 7 above-advantis-ds3.sjc.above.net (216.200.0.81) 21.833 ms 24.418 ms 29.271 ms 8 core1-core4-oc3.sjc.above.net (216.200.0.85) 25.864 ms 23.882 ms 17.173 ms 9 core2-core1.sjc.above.net (209.133.31.110) 47.734 ms 39.032 ms 39.107 ms 10 main2-core2.sjc.above.net (207.126.96.138) 44.072 ms 40.088 ms 40.069 ms 11 core2-main2.sjc.above.net (207.126.96.137) 42.369 ms 44.488 ms 46.094 ms 12 * * core3-core2-oc3.iad.above.net (209.249.203.65) 590.011 ms 13 abov-core1-mae-east.netaxs.com (209.249.119.234) 695.855 ms 721.634 ms 848.819 ms 14 dn-netaxs-gw.dc-core.h5-0-45M.netaxs.net (207.106.127.94) 1125.874 ms 1282.923 ms 1408.877 ms 15 h900.ca2.wdc.dn.net (209.207.190.5) 1263.551 ms 1250.176 ms 1252.700 ms 16 209.207.174.23 (209.207.174.23) 1234.975 ms 1256.689 ms 1208.096 ms
and worse yet DNS lookups from here going thru Vienna:-(
But remember folks there's redundancy in the backbone routing but when something big goes down everyone else gets to suffer as the traffic gets piled on top of their usual connections.
If there's a lot of traffic going thru Europe I bet they're getting really steamed over there
actually I think it's slightly different from what you describe (see my full explanation below) they do this so they can translate the code without having to worry about x86 exception semantics (like where the PC is or what values the various registers or flags have). And they assume that they don't take any excpetions - if they don't all is cool - they know the state at the end of the basic block (or whatever unit they are using for translation - hopefully they're doing better than simple basic blocks).
If they DO get an exception... then they use the described hardware to throw away the side effects of executing the code fragment, and interpret the x86 instructions from the start - doing all the proper instruction semantics.. when they get the exception again this time they know what the PC is and what all the flags and registers etc are
basicly you want to be able to translate say x86 code into some other native instruction set and not to have to worry (too much) about x86 exception semantics or context... you do the high performing translation for the common case and have your hardware pick up any exceptions - meanwhile you have your hardware not commit any memory system changes (the store buffer) until you know your code fragment ran without exceptions - then you commit the changes to memory - if you take an exception you back off and emulate the code fragment probably x86 instruction by instruction (that way you find out which x86 instruction caused the problem etc etc and the x86 state looks clean to the x86 program).
Chances are the code fragments are basic blocks (between branches etc)
I think I've seen this idea by another name before so I'd guess there's prior art - but hey it's a patent you can read anything the lawyers can get away with into it....
pretty much - it does need to be terminated carefully (at the end of the chain) - the SIMMs on a RamBus motherboard are really a chain of SIMs unlike traditional DRAM where it's more of a a bus structure. Signal levels are changed to match loads on the fly - the hardware (or software) does a statistical measurement of error rates at power on time to find a sweet spot to drive the bus at (basicly a measurement of the channel impedance plus the impedance of the drivers on the chip) to figure out how much current to sink in order to swing the signals at the correct levels.
The packetting scheme is much simpler than IP (these days it's not even really a packetting scheme in the sense that earlier RamBus protocols were) etc and NOT collision based (although they did flirt with that in very early versions) - the memory controller is the master and controlls all the bus usage and bandwidth.
I'm a chip designer - I've designed both Rambus memory systems and more traditional ones
Here's the skinny - (the latest) Rambus transfers data on a 16-bit bus at up to 800MHz (400MHz clock data moving on both edges) that's 1.6Gb/sec/channel. PC133's moving data on a 64-bit bus at 133MHz - that's 1.064GB/sec. EV6 (K7) moves 64-bit data on a 200MHz bus - but is limited by having a traditional memory backend (SDRAM performas as above, 100MHz DDR would give the full 1.6G).
Rambus has a major downside - slightly higher latency to memory (this has been somewhat mitigated in the latest RamBus incarnation).
It also has a really major upside - memory granularity - as memory densities go up if you don't need to increase your total memory you can use fewer and fewer RamBus DRAMs and still get the same performance - and you can upgrades at a chip level rather than SDRAMS which you must upgrade in increments of a whole SIMM. For low end PCs this will start to become important (unless M$ manages to waste another 64Mb in Win2K).
Another Rambus advantage is that it can handle many more parallel transactions (esp. overlapping RAS precharge and sense operations because it can have a lot more independant banks in memory) today this isn't so important (except maybe for graphics operations) because to get a big advantage from this you need a lot of concurrent transactions in the memory system and todays CPUs on bridges on the other side of buses don't see as much as you'd like - put directly it on the CPU and there's much more scope for performnce increases - esp. with ISAs like IA64 where much more memory system parallelism is exposed to the programmer.
On the purely physical side there is one other major RamBus down side - mostly because they're pushing the envelope with respect to clock speeds - building working memory systems is harder - PC board tolerences are much tighter (including on the SIMMS) and the bus interface is really analog rather than the digital one most designers are used too - my experience has been that it takes more chip debug time to get a working reliable RamBus system you have to fiddle and tweak a lot untill you have robust workable system - I have no inside knowledge but I suspect that Intel is working through exactly these issues.
I'm for real, I'm an architecture junkie and sometimes chip monkey..... no I don't work for them.
He asked for entries in the pool for "what they will announce".
My ideas are based on public stuff I've seen on the net, where the bleeding-edge-state-of-the-art is and what I know about the problems they may be trying to solve. I have no special knowledge from behind the transmeta non-reality zone
As many people have pointed out there's so much prior art in SF it's not funny (I'd add the Chunk Kao series to the above list).
But of course the guy's wasted his money with his patent lawyer - the patent's gonna run out before the technology is available and now there's prior art on the books at the patent office - when the time comes to start uploading people no one can own it - in reallity I think he's done us a favor
It's just a way to get around the limitation that Intel puts on the number of CPUs in an SMP environment (it's limited by the number of request pins on the chip - the essence of this patent is that you can put a whole bank of CPUs in one spot on 1 request pin on each chip in the other spot).
It's even more history because the scheme doesn't work with the PIIs/celereons being sold today (because if a chip has N request pins then you can put N-1 in a cluster - with their 2 pins you get 2 clusters of 1 cpu which is the same as 2 CPUs so it's kinda pointless) it would work on xeons but their a bit too upmarket
it's an asian fruit - it has a fibrous outside and several internal pockets containing the bits that are good to eat - they're kind of creamy white
this is one of those things which you either like or hate - I've heard them described as smelling like "rotten kerosene" - they have a decidedly pungent smell - the day someone actually did bring one into work it stunk up the whole building.
On the other hand a friend of mine from Singapore loves them, she claims they have a sensuous taste (after you get past the smell) - and it's kinda like garlic (but more so) - once you start eating it you tend to smell of it and people who aren't eating it tend to stay away from you.
I've see 'no durian' signs in Asian airports (picture of fruit in red circle/slash) - you can get them here in the US - but it's not easy (I have no idea how they transport them here)
Slashdot Mirror
ah - you missed the obvious .... the label was on the plastic bottle, not the water ..... it's the bottle that will go off (the water tastes the same .... it's all those little disolved bits of plastic bottle that will make it taste crappy)
Anyway you get my point the 'patent pending' stuff is purely marketting speak to try and get you to buy the thing
PS: I WANT ONE!
>Modern chips aren't designed in manual tools anymore.
actually I was talking about both. These days we still design high performance datapaths by hand, ram too and in particular the standard cells that our automatic synthesis and P&R use as building blocks
Design of these is done as a stack of 2d layers (metal on top with silicon at the bottom) It used to be that capacitance extraction was a pretty simple thing to do and not that important a reasonable approximation was all that was needed - these days extraction is much more difficult - it has to be done in 3D and includes all the interactions between a wire and allthe other objects that come close to it along its whole length - time was just did capacitance to the substrate and got a good estimate - now days you have to worry about edge effects and wire delays (distributed RC delays along the wire because they've got so thin they have appreciable resistance - this is the real reason copper is important - RC delays are smaller - not just that the wires can carry more current)
Certainly we don't have tools that take simple 3D effects into account while working (even many routers can't take the time to do full extractions while they run - they have to do approximations in order to work at all).
But what I was getting at was that we don't have layout tools or P&R tools that could be used to automatically place gates on top of each other (building stacks of silicon stuff rather than one set of layers of silicon stuff and lots of wires) there's so many sorts of analogish leakage issues that would kick in it would be a nighmare
I'm not an expert on quantum computing but is seems that those sorts of structures where electrons are contained by quantum effects rather wires, poly and diffusion may be more amenable to stacking since the quantum barriers could provide a sort of 'insulation' between devices in multiple dimensions that might not be possible in bulk silicon
well maybe not as much as you think - this article is from a process guy - he's talking about what can be made economically - basicly (at a first approx) you take the cost of running a wafer thru the fab then remove the number of bad dies and divide the wafer cost over the good ones - more good dies/wafer (aka 'yield') lower cost/die.
Double the size of the dies and the yield goes down - assume there are 50 bad spots on the wafer with 200 die/wafer you get roughly 75% yield, double the die size you get 100 die/wafer and only 50% yield - you have to charge 3 times as much for the 50 good 2x sized die as you charge for the 150 1x size die to pay for the wafer - this is a made up example intended to show the effect - in practice it's not a linear curve but something with a knee in it where yield drops suddenly.
On the other hand per-die packaging costs are more related to the number of pins which may be the same for 2 cpus vs one
Anyway - my point - putting 2 CPUs on a die without the process improvements that have been basicly driving Moore's law (at the chip level anyway) won't get you the same sorts of improvement that reducing feature size every 18 months or so.
Having said this there are other, better, reasons for putting multiple cpus/die that are starting to kick in (they have more to do with locality of signals withing dies at high clock speeds - you can't run a wire across a chip anymore - better to build multiple independant thingys each in its own corner) - however good SMP software is what's holding this back
The basic idea is that you can't RELIABLY produce sub 100 atom wide structures and have them yield when your basic technology is dump some liquid on a surface to etch it, time how long it's on there, then wash it off - you have to get the solution at exactly the same concentration to every spot on the wafer at exactly the same time, then get it off all at the same time - so that some areas don't etch too much (or too little) - then you need to do the same thing several times for each layer .....
What you might NOT see are traditional 2-D FET based stuff - I expect that what we may see in the future are 3 things:
>> system features that Windows NT 4.0 haspioneered such as
>> asynchronous I/O...
> .... IIRC ext2 is asynchronous by default.
actually what I think they are getting at is the asynchronous I/O interface provided to users .... which NT of course didn't pioneer - they stole it from VMS - an almost 20 year old OS .....
Besides - this is so much FUD - Linux/Unix has threads which are functionally equivalent to signal based asynchronous I/O ... and have an easier to program API.
This isn't so much a bad thing Merced was announced in a similar manner MANY years ago - people should take anything you heer this week about the distant future (ie 2+ years) with a grain of salt - chips take a long time to bring to market and always change a lot during the process - remember they are announcing their goal - not new silicon that's sampling to customers - these are VERY different things.
This sounds like a noise problem to me (whether it's the motherboard that's too noisy or the chip that's too sensitive to it or a combination of both is not obvious) I bet they can fix at least some of this by quieting down the Mobo environment .... but it may also point to the reason they're not deploying a direct K7 competitor (they can't they're running on the hairy edge at the moment) and instead are trying to put price pressure on AMD
BTW I still remember when e-mail and news to .au started up ..... bandwidth was OK but latency was low .... (something to do with how long it took to air-mail those mag tapes full of UUCP spool files across the pacific :-)
Of course when nuclear war hits it will take at least 3 hours to fix ....
>Wouldn't you love to have 40gig of bandwith piped into your home? ;)
:-)
A friend of mine does - he runs an ISP that only resells
bigish pipes (frame relay, T1 etc) out of his basement.
He claims to have more incoming bandwidth to his house
than Australia
Well - that would explain this:
:-(
1 198.182.167.17 (198.182.167.17) 0.628 ms 0.564 ms 0.532 ms
2 adsl-63-194-218-254.dsl.snfc21.pacbell.net (63.194.218.254) 26.688 ms 29.433 ms 15.868 ms
3 core1-fe4-1-0.snfc21.pbi.net (206.171.134.209) 13.394 ms 13.701 ms 15.957 ms
4 gsr1-g1-0.snfc21.pbi.net (209.232.130.20) 16.098 ms 13.846 ms 15.215 ms
5 sfra1sr3-so-1-1-1-0.ca.us.prserv.net (165.87.161.74) 16.676 ms 16.208 ms 15.202 ms
6 sfra1sr2-11-0-0.ca.us.prserv.net (165.87.13.17) 16.684 ms 16.286 ms 15.226 ms
7 above-advantis-ds3.sjc.above.net (216.200.0.81) 21.833 ms 24.418 ms 29.271 ms
8 core1-core4-oc3.sjc.above.net (216.200.0.85) 25.864 ms 23.882 ms 17.173 ms
9 core2-core1.sjc.above.net (209.133.31.110) 47.734 ms 39.032 ms 39.107 ms
10 main2-core2.sjc.above.net (207.126.96.138) 44.072 ms 40.088 ms 40.069 ms
11 core2-main2.sjc.above.net (207.126.96.137) 42.369 ms 44.488 ms 46.094 ms
12 * * core3-core2-oc3.iad.above.net (209.249.203.65) 590.011 ms
13 abov-core1-mae-east.netaxs.com (209.249.119.234) 695.855 ms 721.634 ms 848.819 ms
14 dn-netaxs-gw.dc-core.h5-0-45M.netaxs.net (207.106.127.94) 1125.874 ms 1282.923 ms 1408.877 ms
15 h900.ca2.wdc.dn.net (209.207.190.5) 1263.551 ms 1250.176 ms 1252.700 ms
16 209.207.174.23 (209.207.174.23) 1234.975 ms 1256.689 ms 1208.096 ms
and worse yet DNS lookups from here going thru Vienna
But remember folks there's redundancy in the backbone routing but when something big goes down
everyone else gets to suffer as the traffic
gets piled on top of their usual connections.
If there's a lot of traffic going thru Europe I
bet they're getting really steamed over there
If they DO get an exception ... then they use the described hardware to throw away the side effects of executing the code fragment, and interpret the x86 instructions from the start - doing all the proper instruction semantics .. when they get the exception again this time they know what the PC is and what all the flags and registers etc are
Chances are the code fragments are basic blocks (between branches etc)
I think I've seen this idea by another name before so I'd guess there's prior art - but hey it's a patent you can read anything the lawyers can get away with into it ....
The packetting scheme is much simpler than IP (these days it's not even really a packetting scheme in the sense that earlier RamBus protocols were) etc and NOT collision based (although they did flirt with that in very early versions) - the memory controller is the master and controlls all the bus usage and bandwidth.
Here's the skinny - (the latest) Rambus transfers data on a 16-bit bus at up to 800MHz (400MHz clock data moving on both edges) that's 1.6Gb/sec/channel. PC133's moving data on a 64-bit bus at 133MHz - that's 1.064GB/sec. EV6 (K7) moves 64-bit data on a 200MHz bus - but is limited by having a traditional memory backend (SDRAM performas as above, 100MHz DDR would give the full 1.6G).
Rambus has a major downside - slightly higher latency to memory (this has been somewhat mitigated in the latest RamBus incarnation).
It also has a really major upside - memory granularity - as memory densities go up if you don't need to increase your total memory you can use fewer and fewer RamBus DRAMs and still get the same performance - and you can upgrades at a chip level rather than SDRAMS which you must upgrade in increments of a whole SIMM. For low end PCs this will start to become important (unless M$ manages to waste another 64Mb in Win2K).
Another Rambus advantage is that it can handle many more parallel transactions (esp. overlapping RAS precharge and sense operations because it can have a lot more independant banks in memory) today this isn't so important (except maybe for graphics operations) because to get a big advantage from this you need a lot of concurrent transactions in the memory system and todays CPUs on bridges on the other side of buses don't see as much as you'd like - put directly it on the CPU and there's much more scope for performnce increases - esp. with ISAs like IA64 where much more memory system parallelism is exposed to the programmer.
On the purely physical side there is one other major RamBus down side - mostly because they're pushing the envelope with respect to clock speeds - building working memory systems is harder - PC board tolerences are much tighter (including on the SIMMS) and the bus interface is really analog rather than the digital one most designers are used too - my experience has been that it takes more chip debug time to get a working reliable RamBus system you have to fiddle and tweak a lot untill you have robust workable system - I have no inside knowledge but I suspect that Intel is working through exactly these issues.
I'm for real, I'm an architecture junkie and sometimes chip monkey
for them.
He asked for entries in the pool for "what they will announce".
My ideas are based on public stuff I've seen on the net, where the bleeding-edge-state-of-the-art is and what I know about the problems they may be trying to solve. I have no special knowledge from behind the transmeta non-reality zone
not only that but the original was written (without the god clause) by a Christian Socialist ... so next time complain that it's commie propaganda :-)
But of course the guy's wasted his money with his patent lawyer - the patent's gonna run out before the technology is available and now there's prior art on the books at the patent office - when the time comes to start uploading people no one can own it - in reallity I think he's done us a favor
It's even more history because the scheme doesn't work with the PIIs/celereons being sold today (because if a chip has N request pins then you can put N-1 in a cluster - with their 2 pins you get 2 clusters of 1 cpu which is the same as 2 CPUs so it's kinda pointless) it would work on xeons but their a bit too upmarket
this is one of those things which you either like or hate - I've heard them described as smelling like "rotten kerosene" - they have a decidedly pungent smell - the day someone actually did bring one into work it stunk up the whole building.
On the other hand a friend of mine from Singapore loves them, she claims they have a sensuous taste (after you get past the smell) - and it's kinda like garlic (but more so) - once you start eating it you tend to smell of it and people who aren't eating it tend to stay away from you.
I've see 'no durian' signs in Asian airports (picture of fruit in red circle/slash) - you can get them here in the US - but it's not easy (I have no idea how they transport them here)
the guy I worked with who said "if that bug is in my code I'll eat a durian" ....... we made him eat it outside ....
I guess it's time to go looking for a keyboard with penguin keys ..... I wonder exactly what a penguin key would do if I pressed it ....