Your average programmer either isn't doing C++ or won't be for long...
That is not to say its a bad language, but its like giving a kid a table saw or oxy acetylene torch. Sooner or later something bad is going to happen. Made worse by the fact that every single person doing C++, thinks they are an expert and proceed to use every obscure feature at the same time.
Modern cars are really too complex to take apart and fiddle with, unfortunately.
Bah, total BS. You can do plenty of fiddling on a modern car before you hit the electronics. Modern hot rod kids start by replacing headers, injectors, boost valves, etc. The computers all work around that, often to some advantage. Then you start buying alternate fuel/air maps, and other computer mods. There are even open source ECU mods and even open source ECU's. A quick google search like http://www.google.com/search?q=open+source+ECU shows a few. The first hit is "RomRaider" which is a totally GUI application for tweaking the maps and doing real time data logging. You don't even need to know how to program. In fact, with a utility like that you don't really need much in the way of specialized tools to start "tuning" your car. A laptop a couple open source programs (ECUflash) and an OBDII cable and your on your way. Course bricking your only car might suck...
That means a good base in all the essentials of modern society: language skills, math, science, computers, and yes, they should have some experience doing manual labor as well. At least then if they choose to enter the work force they'll know what they're getting themselves into.
Well that is the intent, but good luck finding an electronics class, car repair, shop, or any number of other real life classes in a modern HS. Much less a proper economics, statistics, etc class. It is all reading,ritting and rithmatic. With a little foreign language, history and science thrown in. Whats left, one or two electives and a few odd classes.
There are many things wrong with HS educations, but the push to smaller HS's (to increase graduation rates) also means that its harder to fill a AP calc class much less an AP comp-sci class. It seems to me that the only solutions are to radical to even be considered as possible alternatives with the current climate of cram-test-cram-test. You would think that all this focus on math/reading/etc would have boosted our international ranking on math, but it doesn't appear to have even done that.
I'm going to have a daughter in this mess in a few years, and I don't really know what to do about it. A friend of mine has concluded the only solutions is to use the school as a social club, and do all the teaching himself at night and on weekends. Frankly, it seems to be working pretty well. The off the cuff teaching at the park, in the car, etc has put his daughter way ahead of her classmates. It really makes you wonder what exactly the schools are doing.
Its really a case of "if it isn't broken don't fix it". Frankly, I'm betting that if they created a new service pack for XP (removing the stupid 4G license restriction (its not technical) fixing the stupid issues with 3G HD's (or just repackage paragon), etc). And sold it for $200 as "XP professional improved" the majority of businesses would use it instead. Frankly, 99% of the win7 changes are fluff at the expense of actual application and hardware compatibility problems.
IMHO, one of the primary reasons windows controls such a large percentage of the desktop market is because of the fact that they went to great effort to maintain compatibility. People who didn't care about long term compatibility used UNIX workstations, or mac's and upgraded their whole hardware/application stack every few years. Windows was never the "sexy" choice, but the one people used because it worked. If M$ has decided that application flash/sexy UI's are more important than compatibility then they _WILL_ fail. Its the opposite of vendor lock, flipping the coin at every release to see if your users stick it out with you will eventually result in lost market share.
As an application developer, I no longer consider win32 to be a valid application target as M$ as publicly claimed they want to kill it, but they have yet to provide an alternative that won't require me to rewrite my application every couple of years. There is a reason that the majority of boxed windows applications are win32, its because a number of them were win16 apps and the investment of writing a large native application is to large to consider a proprietary target that may not exist in 5 years. By discouraging native application development they are killing themselves. The quick and dirty business specific VB applications of the past still exist, except fewer and fewer companies are replacing them with.net applications, instead hiring web developers and creating custom intranets, which are just as likely LAMP stacks as anything MS.
That said, even the most complex web applications out there have tiny UI surfaces when compared with even lightweight desktop applications. Moving email and PIM applications to the "cloud" provide the user little benefit, but create huge scalability issues for the provider. Frankly, the web is a crappy replacement, but right now its the best we have.
Your Boeings and Airbuses that serve commercial aviation are inherently stable.
I don't believe its as black and white as stable vs unstable anymore. You yourself point out the fact that the margin of error is very small. My understanding is that the A330 is only stable in an extremely narrow flight envelope. It does have fixed pitch/power settings that can be used if the computers fail, but they are extremely suboptimal, so instead the computer fly's it in ranges that would result in a near instant stall if a human were fully at the controls. The operating theory (before the flight recorder recovery) about why AF447 crashed says that the pilots took to long to get it into the correct pitch/power setting (more than a few seconds) after the computer disabled itself. This stalled the plane, and given the weather situation at the time, it probably wasn't possible to recover.
How much is the average coder paid? $30 an hour? Lets say the monitor has a value of $150, that works out to ~5 hours. Lets say the hypothetical coder, shows up to work, can't find their monitor. Now lets say they complain about it and try to get it reversed for the next two hours. Avoiding that discussion pays for a new monitor, because everyone involved is also getting paid. The coder is sitting in his managers office for an hour at $30, the manager is listening to the problem at $40 an hour. The coder is bitching to two coworkers at $100 an hour. Etc...
Its really a problem of API surface and complexity. Security is easy if you have 10 system calls to check for interactions. When you have 10k its an entirely different problem. Even so, it doesn't mean it can't happen, I'm reminded of the linux brk problem that existed for years (random google link http://www.isec.pl/papers/linux_kernel_do_brk.pdf). All it takes is one minor mistake, and group blindness and it can exist for years. There have been virtual machine exploits too. Of course the surface area for the critical parts of a VM are pretty small allowing it to be studied in detail.
The "Windows Rot" that slowed down Windows as time went on seems to have been eliminated with Win7.
He he he, I haven't had windows rot on a windows machine since I started using NT back in the 90's. There are a few things that do slow windows down ('run' registry keys!), but that isn't rot, as much as just plain old crap that shouldn't be there. On the otherhand, win7 is so slow out of the box, even if it rotted to 1/2 speed no one would notice. I'm a firm believer that any UI drawing that happens as a result of a key or click I create must be complete before I have fully released the key or released the button. I'm the guy running a "MenuShowDelay=0/1" (actually 1 seems to work a little better). By this metric win7 fails miserably.
Defrag on NTFS is like snake oil, it makes people feel better. 99% of the time, it doesn't speed anything up. Like linux, as long as the drive is kept at a reasonable percentage free, windows is fairly smart about keeping files defraged by itself. Of course, you are aware too that the linux filesystems can be fragmented as well, the difference is that linux filesystems don't come with utilities to online defrag them. Instead the response is generally to backup, recreate the filesystem and copy the data back. I believe btfs intends to fix this by having a garbage collector/defrag built in.
Anyway, same thing with the registry cleanup. Setting the "Run" keys to read only solves 99% of windows startup/stupid user problems. Sure the registry can grow quite a bit if the user is constantly installing/uninstalling programs, but in my experience it takes a _LOT_ (hundreds and hundreds) before the registry grows large enough that "cleaning" it makes any difference. In those cases renaming the old user account and creating a new one solves the problem quite nicely because most of the junk ends up being in HKCU.
It would have also shown Bin Laden to be the pathetic hateful little man he really is and probably convinced some of the more marginal extremist people in the world they are heading down the wrong path. Instead this event will harden those same people because they will see it as proof Americans are hypocrites that, when it suits them, just do whatever the hell they want
He may have been hateful, and maybe even pathetic, but little he was not (actually and figuratively). I urge you to find a good English translation of some of the tapes OBL released (you know the ones the news agencies wouldn't play?). While it may be fairly easy to ignore his message, what I think you will discover is that OBL could speak clearly, and his messages weren't the ramblings of a madman. Frankly, compared with the "they hate us for our way of life" BS coming from some of our politicians, I have to wonder if our politicians even watched the tapes.
That said, your right, the fact that we violated a half dozen international laws to assassinate someone who was the leader of a criminal organization rather than just arrest him, will reinforce the viewpoints held by a growing minority of people in the world. Especially, as more and more hard evidence comes out that he was actually unarmed, in bed with his wife.
The obvious danger of putting him on trial, is that the proceedings end up on live CNN and a significant number of people in the US discover the impedance mismatch between what he says, and what our politicians have been saying. Or it becomes a historical record like the Colin Powell speech. With him dead, the historical record can be easily controlled.
For the last ~8 years I've needed extremely fast encryption (and compression) in the project I use. A few years ago when CUDA began to gain traction, I got all excited and actually decided to see what was necessary to make it work and see how fast it was.
Well at the time, I discovered that CUDA enabled encryption is quite fast. The problem is that copying the data segment to the GPU, doing the encryption and then copying the result back is painful. The copies and setup/interrupt/etc add so much latency that it runs at a roughly the same speed as just doing the operation on the CPU. Adding a couple of user/kernel space crossings probably makes the problem even worse. So during this timeframe we used dedicated compression/encryption boards for the customers that needed it fast, and everyone else just got a couple of extra CPU's dedicated to the effort. Now with AES-NI dedicated boards generally aren't necessary. Sure you have to buy a machine specifically with AES-NI right now, but I suspect that with all these instruction set extensions, within a couple of years it will be widespread.
To patch the kernel to support such an ugly hack would be quite stupid, given the fact that AES is already fairly respectable (~100MB/sec or so per CPU) anyone that needs it faster could use blowfish, or find a CPU with AES-NI.
So, raise the gas tax, and put an equivalent tax on the power charging devices used to charge cars. Frankly, I think those devices already need variable charging rate schedules. If nothing else they should be installed on their own meters.
In 10 years everyone is _NOT_ going to be able to drive electric cars unless we get our behinds in gear and start a serious build out of the electric grid. No, I don't believe the studies claiming that if everyone charges their cars at 3AM its not necessary. 1 because not everyone is going to charge their cars at 3AM, and there are a _LOT_ of neighborhoods already running near capacity. Enough that in many places you cant get a permit for an instant hot water heater because your neighbor already has one. Same thing is going to happen, only instead of failing to get the hot water heater, you won't be able to get the car charge station.
I thought those were dead, even apple says the iPOD revenue is declining. All the iPOD people now have iphones and iPADs so they dont need a dedicated music playback device when their phone is always in their pocket.
In general, the larger the die and transistor count, the higher the power requirements (not always true, but generally).
You of course remember that the 386 (fundamentally the same functionality provided by the base ARM instruction set) was implemented in 275 thousand transistors, and that the intel atom has roughly the same transistor count as the P4, yet burns significantly less power. Why is that? Well the first chapter of H&P talks about dynamic power (CMOS mostly burns power switching) being=.6CV^2f. Which initially looks like frequency is linear to power, but its more complex than that because as you reduce frequency you can reduce the V, which is squared! H&P then show that given a situation where you reduce the freq by 15% the power goes down by 60%. So bigger dies don't really mean anything when it comes to power, its more about frequency.
Looking at the current released data about the up and coming atoms (http://techreport.com/articles.x/18866/4) Intel is claiming battery life better than "leading smart phones" by about 10x.
A storage system capable of streaming dozens of GB/sec is well into the millions of dollars
Could have fooled me. I know roughly what our hardware costs and it isn't in the millions (per node), unless that is you try to buy stuff from EMC. Its probably not for a home user, but neither are 4 port FC cards.
BTW: Its not byte aligned instructions in x86 that cause the problems, but variable width instructions. Which of course ARM now supports (although not as bad as x86) via THUMB2, as well as the fact that the most recent ARM versions are also modal decoders, meaning that you have to know what mode the CPU is in before decoding a block of code.
Also, ARM has support byte load for as long as I can remember (always?), and added misaligned loads in ARM6 (IIRC). Its the misaligned load/store that generally causes pipeline problems not a partial word load/store. Furthermore, a really nasty thing that ARM has is load multiple, which pretty much can only be implemented efficiently (think exceptions during load/store) via microcode (or similar functionality).
BTW: Of the processors I write assembly on, ARM is probably my favorite. That said, its one thing to make a CPU consume a few tenths of a watt, its quite another to get what might be considered good performance at the same time. I get excited every time a higher performance ARM is announced, but I'm not sure people understand just how slow they really are. I wish the ARM vendors would start publishing SPEC CINT2006 numbers.
What's your usage scenario that needs data constantly streamed at >600MB/sec
I'm not going to talk about the details, but lets say a normal single machine configuration has 8 fiber channel ports (QLE2564) at 8Gbit/sec. The machine itself is reading manipulating/transforming and writing data at multiple GB/sec, and these things are very often clustered. If you look at the enterprise storage market you might see quite a lot of very interesting hardware. Some of it is built for IOP, some of it is built for bandwidth.
Yah my bad, I just assumed anyone buying FC hardware would want the current generation. I actually looked for a 10Gb FCoE converter too. Google seems to be more and more biased to sites selling stuff, but for obscure things you still have to wade through pages and pages until you find what you want (unless the shopping page has it). I assume someone has a 10Gb Ethernet, but I didn't spend any time looking for those, so I didn't add them to the original list.
Actually my google search was "8Gbit FC to Thunderbolt" which didn't yield the 4Gbit adapters. So there is connectivity, only at 1/2 the current speed (unless there is a 8Gbit one I missed).
See Comp.arch and Andy Glew's postings for reasons that this argument doesn't hold any weight with OoO CPU's or basically anything decoding to an internal micro-ops. This argument made sense when the decoder didn't comprise less than.01% of the CPU die. But for nearly the past decade every-time it comes up in discussions with actual CPU architects they agree the x86 decoder doesn't affect the power or speed of the CPU.
simply no way the x86 architecture can ever go toe-to-toe with the ARM architecture on power efficiency.
Spoken like someone without a clue. There is fundamentally absolutely nothing in x86 that would cause it to consume more power than ARM. If anything the instruction predication in ARM gives x86 an advantage.
As ARM processors get more performance competitive with x86 they are beginning to match the power usage too. The big power advantage in current high performance ARM's is more due to the SOC integration than the architecture. Just wait, I will bet that in another generation or two, the roles will reverse as intel brings a much better fab process/integration, and the huge force of making a limited number of CPU models to bear against the dozens of ARM vendors each trying to optimize their particular design against a generic fab process. Samsung and Renesas might be the only ARM vendors with a chance, but even Renesas seems to prefer the SuperH.
Uh, connecting a RAID array? Current x4 SAS provides 24Gbit per port. Thats ~2x what Light Peak/Thunderbolt can provide. Plus, I don't see any converters to FC so that I can attach to a SAN, or a nice place to put one of these http://www.fusionio.com/products/iodriveoctal. BTW: If your RAID can't saturate 6Gbit SATA then you might think about a different array.
This is./, if apple is claiming the mac is a media platform, then you should be able to connect a decent RAID enclosure. If your raid encloser can't saturate 600MB/sec then you should look for a better setup. The current cutting edge single system disk attachement is _NOT_ sata, but rather SAS x4, which at 6Gbit lanes is 24Gbit per port, or twice what thunderbolt can do.
That generally not how it works. Both X and the old windows GDI were on demand painters. Basically they simply had the application repaint screen as necessary, clipping the non visible regions. Of course caching a portion of the painting speeds things up, but generally if your running out of ram the image is just thrown away. So having 200 windows open doesn't require sufficient ram/graphics memory to contain 200 maximized windows.
Slashdot Mirror
Your average programmer either isn't doing C++ or won't be for long...
That is not to say its a bad language, but its like giving a kid a table saw or oxy acetylene torch. Sooner or later something bad is going to happen. Made worse by the fact that every single person doing C++, thinks they are an expert and proceed to use every obscure feature at the same time.
Modern cars are really too complex to take apart and fiddle with, unfortunately.
Bah, total BS. You can do plenty of fiddling on a modern car before you hit the electronics. Modern hot rod kids start by replacing headers, injectors, boost valves, etc. The computers all work around that, often to some advantage. Then you start buying alternate fuel/air maps, and other computer mods. There are even open source ECU mods and even open source ECU's. A quick google search like http://www.google.com/search?q=open+source+ECU shows a few. The first hit is "RomRaider" which is a totally GUI application for tweaking the maps and doing real time data logging. You don't even need to know how to program. In fact, with a utility like that you don't really need much in the way of specialized tools to start "tuning" your car. A laptop a couple open source programs (ECUflash) and an OBDII cable and your on your way.
Course bricking your only car might suck...
That means a good base in all the essentials of modern society: language skills, math, science, computers, and yes, they should have some experience doing manual labor as well. At least then if they choose to enter the work force they'll know what they're getting themselves into.
Well that is the intent, but good luck finding an electronics class, car repair, shop, or any number of other real life classes in a modern HS. Much less a proper economics, statistics, etc class. It is all reading,ritting and rithmatic. With a little foreign language, history and science thrown in. Whats left, one or two electives and a few odd classes.
There are many things wrong with HS educations, but the push to smaller HS's (to increase graduation rates) also means that its harder to fill a AP calc class much less an AP comp-sci class. It seems to me that the only solutions are to radical to even be considered as possible alternatives with the current climate of cram-test-cram-test. You would think that all this focus on math/reading/etc would have boosted our international ranking on math, but it doesn't appear to have even done that.
I'm going to have a daughter in this mess in a few years, and I don't really know what to do about it. A friend of mine has concluded the only solutions is to use the school as a social club, and do all the teaching himself at night and on weekends. Frankly, it seems to be working pretty well. The off the cuff teaching at the park, in the car, etc has put his daughter way ahead of her classmates. It really makes you wonder what exactly the schools are doing.
Its really a case of "if it isn't broken don't fix it". Frankly, I'm betting that if they created a new service pack for XP (removing the stupid 4G license restriction (its not technical) fixing the stupid issues with 3G HD's (or just repackage paragon), etc). And sold it for $200 as "XP professional improved" the majority of businesses would use it instead. Frankly, 99% of the win7 changes are fluff at the expense of actual application and hardware compatibility problems.
IMHO, one of the primary reasons windows controls such a large percentage of the desktop market is because of the fact that they went to great effort to maintain compatibility. People who didn't care about long term compatibility used UNIX workstations, or mac's and upgraded their whole hardware/application stack every few years. Windows was never the "sexy" choice, but the one people used because it worked. If M$ has decided that application flash/sexy UI's are more important than compatibility then they _WILL_ fail. Its the opposite of vendor lock, flipping the coin at every release to see if your users stick it out with you will eventually result in lost market share.
As an application developer, I no longer consider win32 to be a valid application target as M$ as publicly claimed they want to kill it, but they have yet to provide an alternative that won't require me to rewrite my application every couple of years. There is a reason that the majority of boxed windows applications are win32, its because a number of them were win16 apps and the investment of writing a large native application is to large to consider a proprietary target that may not exist in 5 years. By discouraging native application development they are killing themselves. The quick and dirty business specific VB applications of the past still exist, except fewer and fewer companies are replacing them with .net applications, instead hiring web developers and creating custom intranets, which are just as likely LAMP stacks as anything MS.
That said, even the most complex web applications out there have tiny UI surfaces when compared with even lightweight desktop applications. Moving email and PIM applications to the "cloud" provide the user little benefit, but create huge scalability issues for the provider. Frankly, the web is a crappy replacement, but right now its the best we have.
Your Boeings and Airbuses that serve commercial aviation are inherently stable.
I don't believe its as black and white as stable vs unstable anymore. You yourself point out the fact that the margin of error is very small. My understanding is that the A330 is only stable in an extremely narrow flight envelope. It does have fixed pitch/power settings that can be used if the computers fail, but they are extremely suboptimal, so instead the computer fly's it in ranges that would result in a near instant stall if a human were fully at the controls. The operating theory (before the flight recorder recovery) about why AF447 crashed says that the pilots took to long to get it into the correct pitch/power setting (more than a few seconds) after the computer disabled itself. This stalled the plane, and given the weather situation at the time, it probably wasn't possible to recover.
How much is the average coder paid? $30 an hour? Lets say the monitor has a value of $150, that works out to ~5 hours. Lets say the hypothetical coder, shows up to work, can't find their monitor. Now lets say they complain about it and try to get it reversed for the next two hours. Avoiding that discussion pays for a new monitor, because everyone involved is also getting paid. The coder is sitting in his managers office for an hour at $30, the manager is listening to the problem at $40 an hour. The coder is bitching to two coworkers at $100 an hour. Etc...
1) there is a huge, gaping bug in the OS
Its really a problem of API surface and complexity. Security is easy if you have 10 system calls to check for interactions. When you have 10k its an entirely different problem. Even so, it doesn't mean it can't happen, I'm reminded of the linux brk problem that existed for years (random google link http://www.isec.pl/papers/linux_kernel_do_brk.pdf). All it takes is one minor mistake, and group blindness and it can exist for years. There have been virtual machine exploits too. Of course the surface area for the critical parts of a VM are pretty small allowing it to be studied in detail.
The "Windows Rot" that slowed down Windows as time went on seems to have been eliminated with Win7.
He he he, I haven't had windows rot on a windows machine since I started using NT back in the 90's. There are a few things that do slow windows down ('run' registry keys!), but that isn't rot, as much as just plain old crap that shouldn't be there. On the otherhand, win7 is so slow out of the box, even if it rotted to 1/2 speed no one would notice. I'm a firm believer that any UI drawing that happens as a result of a key or click I create must be complete before I have fully released the key or released the button. I'm the guy running a "MenuShowDelay=0/1" (actually 1 seems to work a little better). By this metric win7 fails miserably.
Defrag on NTFS is like snake oil, it makes people feel better. 99% of the time, it doesn't speed anything up. Like linux, as long as the drive is kept at a reasonable percentage free, windows is fairly smart about keeping files defraged by itself. Of course, you are aware too that the linux filesystems can be fragmented as well, the difference is that linux filesystems don't come with utilities to online defrag them. Instead the response is generally to backup, recreate the filesystem and copy the data back. I believe btfs intends to fix this by having a garbage collector/defrag built in.
Anyway, same thing with the registry cleanup. Setting the "Run" keys to read only solves 99% of windows startup/stupid user problems. Sure the registry can grow quite a bit if the user is constantly installing/uninstalling programs, but in my experience it takes a _LOT_ (hundreds and hundreds) before the registry grows large enough that "cleaning" it makes any difference. In those cases renaming the old user account and creating a new one solves the problem quite nicely because most of the junk ends up being in HKCU.
It would have also shown Bin Laden to be the pathetic hateful little man he really is and probably convinced some of the more marginal extremist people in the world they are heading down the wrong path. Instead this event will harden those same people because they will see it as proof Americans are hypocrites that, when it suits them, just do whatever the hell they want
He may have been hateful, and maybe even pathetic, but little he was not (actually and figuratively). I urge you to find a good English translation of some of the tapes OBL released (you know the ones the news agencies wouldn't play?). While it may be fairly easy to ignore his message, what I think you will discover is that OBL could speak clearly, and his messages weren't the ramblings of a madman. Frankly, compared with the "they hate us for our way of life" BS coming from some of our politicians, I have to wonder if our politicians even watched the tapes.
That said, your right, the fact that we violated a half dozen international laws to assassinate someone who was the leader of a criminal organization rather than just arrest him, will reinforce the viewpoints held by a growing minority of people in the world. Especially, as more and more hard evidence comes out that he was actually unarmed, in bed with his wife.
The obvious danger of putting him on trial, is that the proceedings end up on live CNN and a significant number of people in the US discover the impedance mismatch between what he says, and what our politicians have been saying. Or it becomes a historical record like the Colin Powell speech. With him dead, the historical record can be easily controlled.
For the last ~8 years I've needed extremely fast encryption (and compression) in the project I use. A few years ago when CUDA began to gain traction, I got all excited and actually decided to see what was necessary to make it work and see how fast it was.
Well at the time, I discovered that CUDA enabled encryption is quite fast. The problem is that copying the data segment to the GPU, doing the encryption and then copying the result back is painful. The copies and setup/interrupt/etc add so much latency that it runs at a roughly the same speed as just doing the operation on the CPU. Adding a couple of user/kernel space crossings probably makes the problem even worse. So during this timeframe we used dedicated compression/encryption boards for the customers that needed it fast, and everyone else just got a couple of extra CPU's dedicated to the effort. Now with AES-NI dedicated boards generally aren't necessary. Sure you have to buy a machine specifically with AES-NI right now, but I suspect that with all these instruction set extensions, within a couple of years it will be widespread.
To patch the kernel to support such an ugly hack would be quite stupid, given the fact that AES is already fairly respectable (~100MB/sec or so per CPU) anyone that needs it faster could use blowfish, or find a CPU with AES-NI.
So, raise the gas tax, and put an equivalent tax on the power charging devices used to charge cars. Frankly, I think those devices already need variable charging rate schedules. If nothing else they should be installed on their own meters.
In 10 years everyone is _NOT_ going to be able to drive electric cars unless we get our behinds in gear and start a serious build out of the electric grid. No, I don't believe the studies claiming that if everyone charges their cars at 3AM its not necessary. 1 because not everyone is going to charge their cars at 3AM, and there are a _LOT_ of neighborhoods already running near capacity. Enough that in many places you cant get a permit for an instant hot water heater because your neighbor already has one. Same thing is going to happen, only instead of failing to get the hot water heater, you won't be able to get the car charge station.
I thought those were dead, even apple says the iPOD revenue is declining. All the iPOD people now have iphones and iPADs so they dont need a dedicated music playback device when their phone is always in their pocket.
Read this too...
http://techreport.com/articles.x/18866/4
In general, the larger the die and transistor count, the higher the power requirements (not always true, but generally).
You of course remember that the 386 (fundamentally the same functionality provided by the base ARM instruction set) was implemented in 275 thousand transistors, and that the intel atom has roughly the same transistor count as the P4, yet burns significantly less power. Why is that? Well the first chapter of H&P talks about dynamic power (CMOS mostly burns power switching) being=.6CV^2f. Which initially looks like frequency is linear to power, but its more complex than that because as you reduce frequency you can reduce the V, which is squared! H&P then show that given a situation where you reduce the freq by 15% the power goes down by 60%. So bigger dies don't really mean anything when it comes to power, its more about frequency.
Looking at the current released data about the up and coming atoms (http://techreport.com/articles.x/18866/4) Intel is claiming battery life better than "leading smart phones" by about 10x.
A storage system capable of streaming dozens of GB/sec is well into the millions of dollars
Could have fooled me. I know roughly what our hardware costs and it isn't in the millions (per node), unless that is you try to buy stuff from EMC. Its probably not for a home user, but neither are 4 port FC cards.
I'm feeling particularly bored today..
BTW: Its not byte aligned instructions in x86 that cause the problems, but variable width instructions. Which of course ARM now supports (although not as bad as x86) via THUMB2, as well as the fact that the most recent ARM versions are also modal decoders, meaning that you have to know what mode the CPU is in before decoding a block of code.
Also, ARM has support byte load for as long as I can remember (always?), and added misaligned loads in ARM6 (IIRC). Its the misaligned load/store that generally causes pipeline problems not a partial word load/store. Furthermore, a really nasty thing that ARM has is load multiple, which pretty much can only be implemented efficiently (think exceptions during load/store) via microcode (or similar functionality).
BTW: Of the processors I write assembly on, ARM is probably my favorite. That said, its one thing to make a CPU consume a few tenths of a watt, its quite another to get what might be considered good performance at the same time. I get excited every time a higher performance ARM is announced, but I'm not sure people understand just how slow they really are. I wish the ARM vendors would start publishing SPEC CINT2006 numbers.
What's your usage scenario that needs data constantly streamed at >600MB/sec
I'm not going to talk about the details, but lets say a normal single machine configuration has 8 fiber channel ports (QLE2564) at 8Gbit/sec. The machine itself is reading manipulating/transforming and writing data at multiple GB/sec, and these things are very often clustered. If you look at the enterprise storage market you might see quite a lot of very interesting hardware. Some of it is built for IOP, some of it is built for bandwidth.
Yah my bad, I just assumed anyone buying FC hardware would want the current generation. I actually looked for a 10Gb FCoE converter too. Google seems to be more and more biased to sites selling stuff, but for obscure things you still have to wade through pages and pages until you find what you want (unless the shopping page has it). I assume someone has a 10Gb Ethernet, but I didn't spend any time looking for those, so I didn't add them to the original list.
Actually my google search was "8Gbit FC to Thunderbolt" which didn't yield the 4Gbit adapters. So there is connectivity, only at 1/2 the current speed (unless there is a 8Gbit one I missed).
: the instruction decoder in x86 is more complex.
See Comp.arch and Andy Glew's postings for reasons that this argument doesn't hold any weight with OoO CPU's or basically anything decoding to an internal micro-ops. This argument made sense when the decoder didn't comprise less than .01% of the CPU die. But for nearly the past decade every-time it comes up in discussions with actual CPU architects they agree the x86 decoder doesn't affect the power or speed of the CPU.
simply no way the x86 architecture can ever go toe-to-toe with the ARM architecture on power efficiency.
Spoken like someone without a clue. There is fundamentally absolutely nothing in x86 that would cause it to consume more power than ARM. If anything the instruction predication in ARM gives x86 an advantage.
As ARM processors get more performance competitive with x86 they are beginning to match the power usage too. The big power advantage in current high performance ARM's is more due to the SOC integration than the architecture. Just wait, I will bet that in another generation or two, the roles will reverse as intel brings a much better fab process/integration, and the huge force of making a limited number of CPU models to bear against the dozens of ARM vendors each trying to optimize their particular design against a generic fab process. Samsung and Renesas might be the only ARM vendors with a chance, but even Renesas seems to prefer the SuperH.
Uh, connecting a RAID array? Current x4 SAS provides 24Gbit per port. Thats ~2x what Light Peak/Thunderbolt can provide. Plus, I don't see any converters to FC so that I can attach to a SAN, or a nice place to put one of these http://www.fusionio.com/products/iodriveoctal. BTW: If your RAID can't saturate 6Gbit SATA then you might think about a different array.
This is ./, if apple is claiming the mac is a media platform, then you should be able to connect a decent RAID enclosure. If your raid encloser can't saturate 600MB/sec then you should look for a better setup. The current cutting edge single system disk attachement is _NOT_ sata, but rather SAS x4, which at 6Gbit lanes is 24Gbit per port, or twice what thunderbolt can do.
That generally not how it works. Both X and the old windows GDI were on demand painters. Basically they simply had the application repaint screen as necessary, clipping the non visible regions. Of course caching a portion of the painting speeds things up, but generally if your running out of ram the image is just thrown away. So having 200 windows open doesn't require sufficient ram/graphics memory to contain 200 maximized windows.