I'm to lazy to double check, but mouse control ended up in doom after the doom 2 release (1.666?). I played a crapload of multiplayer doom my sr year in hs. I was the best out of maybe a dozen friends. Then I started college and stopped playing, until christmas break or some such. When we all got back together a couple friends from gtech totally kicked my backside because they had been playing doom 2 with the mouse in the labs. It took me maybe 5 hours to conclude I had to switch. The reason was simple (this predated mouse look), you could turn faster, and it made all the diffrence.
I didn't see anyone else mention this, but on windows and AIX, one of the reasons for using a binary log format is internationalization. Log messages are little more than application/facility id, log id, and parameters. The when the user displays the message the ids are looked up in a localization table and formatted according to the attached parameters.
Still hasn't started transitioning their HP-UX, Nonstop, etc customers to something else. It generally takes a generation or two before all the lagards get on board a new arch. Heck, HP was still selling PA-RISC machines a couple years ago, long past the point where it was apparent the itanic was a dead end.
It seems that HP is intended to keep forcing intel to make the itanium forever, but they have to have a fallback plan. The question is, does HP want to pay for full development of a chip so complex it takes 10x the manpower to design for, or are they going to bring back something like PA-RISC or Alpha that goes fast, without to much effort. Their only other alternatives seem to be jumping on the x86 or POWER bandwagon. I might included sparc, but outside of fujitsu, that seems pretty dead too.
Which for anyone not playing quake was an absolutely fantastic CPU. I had one of the PR166 (aka 133Mhz, IIRC its was actually an IBM) ones, and it absolutely trounced my roommates P90 (which actually cost a little more), in everything. It was actually pretty amazing. Then there was quake, which was hand optimized for the pentium U-V pipeline arch and made heavy use of FP. The results was that in quake my PR166 @ 133Mhz was performing on par with the 90Mhz Pentium which cost about the same amount of money. I didn't understand the smear campaign back then, and I still don't. Everyone insisted on comparing the PR166 against the P166 which cost significantly more, and complaining when it didn't best it in one or two benchmarks. Dollar for dollar the PR166 kicked the crap out of anything Intel offered. In its worse case it was roughly equal to the equivalently priced pentium, but in its best case was equal to a processor that cost ~3x more.
The general consensus was that the cyrix had crappy floating point, but the cycle latencies were actually equal or better than the Pentium, what killed it was its inability to execute pentium scheduled FP code efficiently. I rolled a couple microbencmarks of my own just doing streaming multiplies and divides and the cyrix could actually beat the Pentium at the same clock rate when the code wasn't explicitly optimized for the Pentium (aka 486 scheduled FP was faster on the cyrix than the P).
Then there was the mystery of why Microsoft disabled the L2 CPU cache in NT when using a cyrix... Which is another whole discussion.
In all, the only real gripe I had about the CPU was its absolute need for good cooling. Without a good fan/heat-sink properly applied it would crash.
RS232 devices are not real "RS232", but implement "compatible 3/5-wire" serial communication.
Well, invariably a lot of applications don't need all the extra signal pins, things like carrier detect are pointless with a cabled null connection. The addition of FIFO's and CPU's that are millions of times faster also reduced the need for the DSR/DTR, RTS/CTS flow control. But none of this is really a problem. The really ugly problems come from the devices that are two cheap to use charge pump line drivers, and claim RS232 compatibility while only driving 5V.
All that said, a big portion of the advantage of RS232 on the PC has to do with the fact you can talk to COM1/2 on most pcs at a fixed IO port address (and hence one of the many reasons why USB converters aren't a replacement).
no character encoding, no protocol auto-detection, no data compression, no "real" error correction, so comparing it to modern interfaces such as ethernet, firewire or usb is a bit like comparing apples to oranges.
ethernet/usb/etc have compression in the protocol? Could have fooled me. The lack of autobaud is a weakness and probably the main failing of the protocol. More recent devices (aka lots of the USB serial converters) actually do have autobaud and it works pretty well.
The lack of error correction isn't a problem for RS232. In a way this is an advantage too. RS232 data rates are so slow that its possible to get a very clean signal. Sure its also easy to have bad cables, or external interference on long runs. I've done enough programming with RS232 and more modern interfaces to say that in the end having error correction on the line doesn't do a damn thing for application level programs. That is because small error rates that are hidden by the error correction are rare. Invariably the problem is severe enough to require someone to go investigate why the application fails or is running slowly. Discovering you have a bad USB cable dropping a bit here/there resulting in 90% packet loss, is no different from discovering you have a cable flipping a few bits on your rs232 line and are retransmitting 90% of your packets. Simple devices, on short runs (think keyboards), work equally well on serial protocols without error correction (ps/2) as they do on ones with error correction (USB). For more complex systems the error detection, and retransmit logic needs to be pushed into the higher level protocols anyway. Adding a simple CRC on the end of a packet going down RS232 is incredibly easy and gives you a lot of protection.
I'm not necessarily arguing that we should be putting 4 serial ports on PCs, but removing the last one on a desktop machine so we can have 12 USB ports instead of 10 is silly. The weekly discussion on the ntdev mailing lists, or similar ones for linux, about getting the kernel debuggers working, invariably result in someone suggesting the developer take the machine apart and locate the unsoldered RS232 headers and soldering on a connector.
Its the KISS principal (something that many people on this board fail to understand). RS232 is so simple the entire hardware/software interface can be implemented in a handful of gates, and a few dozen lines of code. Plus, the PC 8250 interfaces one of the few things you can actually depend on when the proverbial crap hits the fan. Both windows and linux kernel debuggers run over RS232. There have been numerous attempts at making ethernet, firewire, usb interfaces, but invariably they die and boring old RS232 keeps on chugging.
Plus, basic rs232 type interfaces are everywhere in real life. From industrial machines, to the insides of a huge percentage of usb peripherals with simple USB to serial converters interfacing to the actual hardware.
Then there is the fact that you can run 50' rs232 cables..
Is that a lot of it comes from having the engineer on the factory floor talking to the machinist/whatever.
If you don't know where the manufacturing difficulties are, then you can't redesign it, and produce the next generation that is lighter/faster/cheaper/whatever.
Sitting in an ivory tower playing with CAD/simulations only gets you so far. Eventually you have to actually build it, its then that you discover that you design cannot be built, or it fails in some catastrophic manner. This happens far more than anyone is willing to admit.
The same is true of software, this year you teach a bunch of people how to create your product. Next year, they build their own without you. Now instead of those jobs being the next town over, they are in some foreign country where the cost of living is 1/1000th and you simply cannot compete.
Globalization is great, if your china/india/etc and have a surplus of labor. For everyone else, other than those that can exploit the foreign workers it sucks.
Many common programming tasks require extensive pointer manipulation in C.
Pointer arithmetic, or pointer storage (aka linked lists?), or argument passing?
Frankly, I suspect you have been reading your old copy of K&R to much. Most modern (aka written in the last 20 years, by experienced developers) C rarely does pointer arithmetic. There isn't any reason, as the compilers/CPUs started being able to optimize the array syntax (var[offset]) to perform equivalently (if not faster) than similar pointer based code. When that happened the readability/debuggability/security aspects outweighed the slight performance difference of doing it the way K&R demonstrated in the 70's. The problem is that to many newbies listen to the old guys, talking about how great the K&R book is for learning C, and proceed to mimic many of the harmful tricks and styles in that book.
Bah, I cut the cable 7 or 8 years ago, primary because I refuse to pay for crappy programming with commercials.
I don't miss cable one bit, on the other-hand the ~10 channels I get over the air actually are pretty nice. I get 3 PBS's, and the large broadcast affiliates, which provide local news (for what its worth), and assorted other "entertainment".
Giving that spectrum to AT&T isn't going to do a darn thing to increase your bandwidth (shared medium with long haul transmission capabilities) and you can bet the telcoms will charge you for every byte you download from it.
All that said, there is also the quality issue. I have yet to see a single streaming "HD" video, that even approaches the quality of ATSC 1080i. Netflix looks great on a 19" screen. It looks horrible on a 42" much less a 60". Subjectively, I find their HD streams look slightly worse than a upscaled DVD, and that is with a 30Mbit internet connection. This doesn't mean I'm complaining about it, just that once in a while I like to see actual HD quality video. For that I flip on the ATSC receiver, stream a ripped title from the PC, or put an actual piece of media in the home theater stack.
Find something that excites you, is completely new to you, and doesn't have a million other people doing the same thing.
For me, that has been things like, finding a small microcontroller and writing a tiny OS to run on it (long before that became the cool thing to do).
Building a small embedded appliance, by designing the PCB, and a couple small pieces of code.
Writing a compression algorithm, using GPGPU.
A temp dependent overclocking utility.
Witting a web javascript UI toolkit to do overlapping windows & WIMP style programming.
The trick is to find something completely new, so your constantly learning something (be that a language, piece of hardware, environment, etc). Then you have to come up with something that hasn't been done on that platform before. Then when it gets boring, dump it. Doesn't matter if its finished or not, just go do something else that excites you. Often if you pick the right project, it will remain exciting well beyond the point where it is working. Even better, sometimes beyond the personal growth, if you post it to sourceforge, an app store, etc you will find others that are interested in it and it becomes a chance to earn a little $. Then in some cases one thing leads to another. Don't expect to get rich, or set unrealistic goals. In other-words reject ideas outright that seem like they might take more than a couple months. The idea is for this to be fun, not a second job. In the past it used to bother me, the dozens of 1/2 finished projects I started. Then I realized it was better that way. Now I don't struggle to finish something, if it gets boring, I just do something else. I still learn a crapload, and my cool geek friends think 1/2 finished partially working projects are just as cool as fully working ones. They see the potential. Plus, the amount of $ made when I do finish something is rarely more than the equivalent of a minimum wage job.
I agree with your points in general, but this stood out:
For example, backup tapes greatly benefit from compression, because they have relatively slow transfer rates to begin with
Uh, you know that current tape drives (T10k, 359x, even LTO) all have physical media transfer rates between 140 (LTO5) and 250MB/sec (3592E07)? With compression it possible to get over 350-600MB/sec (depending on drive & compression ratio) on all the current generation drives. So, yes compression helps, but the drives aren't slouches. In the end, even a modest library with a dozen drives probably has more bandwidth than most companies combined disk subsystems. The backup bottlenecks are almost always how fast can the changed data be sourced from the array. Most of the "enterprise" backup solutions have some disk stage component built into them now, that sources from multiple servers, and then writes the result to a single tape drive. The problem is that a lot of places fail to realize that they cannot just create a media server out of a random dell/HP/IBM machine, instead they need to attach extremely fast disk on the staging machine. Of course this problem is made worse by the fact that none of the major storage vendors see fit to sell a medium capacity disk (50-100T) with gigabytes of IO bandwidth for just a few thousand dollars. For that you have to look at the 3rd tier storage vendors.
Probably worth pointing out that compression will often actually improve disk IO.
Well, not really. If that were true then windows would probably enable folder compression by default. Besides latency issues that someone else pointed out, the overhead of doing something like updating 512 bytes in the middle of a file is significantly faster with an uncompressed file than a compressed one. Furthermore, streaming read/writes are where a the compressed filesystem gains advantages. In those cases the amount of advantage is dependent on the actual performance of the CPU's, compression ratios, and drives involved. Its also dependent on the question of whether there is a CPU sitting around idle. Anyway, the actual performance of a high speed algorithm like LZO (or LZS in the old days) has never really been much more than 2-4x a single hard-drive (and in some cases worse by similar factors). You should think about how the system performs when the compression ratio of the data is 1.2:1. Then consider that rarely was the compression ratio of a whole volume much greater than 2:1. Any advantages of compressed volumes were easily overcome with just basic software RAID0. Higher end RAID systems were often significantly faster than compression.
A lot of people are saying "I would fire the guy who writes his own x function". That is sort of a valid statement, but you have to consider that is also 99% of the problem with bloat. Say for example I want to md5 something. I could pull in a basic MD5 algorithm, slow but functional in a few hundred bytes. Want it faster? Then add some tables. Or you can just go with the really fast one built into openssl. The problem is you just pulled in another 1M+ of code you have no need for. Sure demand paging then turn around and removes it, but the page table entries, linker fixups, etc are still being created. Multiply that by a hundred or so libraries any non trivial application is using and, pretty soon your looking at a base VM size of a few tens or hundreds of MB.
There is also a lot of hidden functionality in applications today. Consider Unicode capable string functions, network communications code, etc. This is part of the joy of phone/tablet development. You can create an application without all the crap and get away with it.
In which case this makes perfect sense. There is an absolutely massive difference between recommending a spec for a developer machine and stating requirements for building the source.
Furthermore, there isn't any reason to be building on the "developers" machine anyway. That is _SO_ Microsoft... I worked for a company 15 years ago that cured me of that. Ever since, I always recommend build machines. That way you spend a bunch of money getting a fast disk and a lot of CPU's put it in the closet and then the compile speeds don't factor into the decisions on the developers desktop. It also provides a place to have a standard set of libraries/etc in order to get repeatable builds. Takes a little getting used to, but it turns out that most people accept that not everyone can have a 64 thread machine with 128G of ram on their desktop, and once it becomes apparent that not everyone is building at the same time, the speed advantages are readily apparent. Buy a new one every year or so, and the developers machines last longer too.
And people who pay attention to history, understand that is how the US got there too. I remember as a school child learning about Francis Cabot LowellWho "borrowed" the technology to build a power loom in the US and thereby allowing (with the cotton gin/etc) the US to become an exporter of textiles rather than cotton.
This complaint is about the Chinese investing $30 billion in solar energy subsidies. How much have Germany and the U.S. invested in green energy
Yes, and this isn't understood by many of the people in the US, who are busy complaining about Solyndra. Of course if you consider what $40B (not all solar), gets you in the US, vs $30B (all in solar) gets you in China. It doesn't really seem fair, besides being surgically focused (instead of a bunch of pie in the sky BS like much of the $40B), $30B in china goes to pay a lot more workers and build bigger factories than the equivalent sum in the US.
Frankly, I could care less about solar/etc, because the second power actually becomes a problem in the US (due to trade war with china, global coal ban, whatever) and we have a proper discussion, we will start building nukes.
I have a treo 650 from 2004/5. That is what passes for my cell phone. Its nearly indestructible, and its totally user serviceable, unlocked and hackable. I have swapped the battery, screen, keyboard, etc. The parts are becoming a little harder to find but there are still a lot of listings on ebay for complete functional ones for less than $20. Its also got a large selection of applications, Bluetooth, etc. In fact I recently upgraded my 12 year old toyota to a newer model which has voice activated Bluetooth, and the phone just paired right up. I also pay on average less than $10 a month for cell service. So its totally possible, to avoid the cell phone trap of a $50-$100 bill each month.
Personally, I suspect the iphone will be the next phone like this, simply because of its ubiquity. While a total PITA to replace a screen/battery/etc, the absolute number of them will assure a long life on ebay at reasonable prices. Anyone who knows how to unlock and crack the case will have a good supply of parts. Finding batteries will probably be fairly easy too, there are a bunch of 3rd party battery manufactures.
It's likely not to be the case, at least in the short term, hardware will absolutely require some shutdown time, to get to a stable standby state.
And the reinit time to resync the PCIe links, release an IP, etc..
We have similar functionality today in the form of S3 sleep which powers everything down but the RAM. Resuming requires all the drivers to wake their hardware and get it operational again.
What next a conservative that notices that cutting govt spending on teachers, etc in the middle of a (de/re)pression results in worse unemployment. Or that maybe trickle down economics has failed every singe time its been tried (not just in the US). Or that maybe giving large companies more cash in the form of reduced regulations, low interest rates, etc is a 2/3nd order stimulus and is worse than useless when large companies are sitting on cash stockpiles?
But, you know its all about party/dogma over country for a significant percentage of the elected representatives in congress. Otherwise we would actually have a discussion about cap/trade/etc. The problem is that "raising" taxes in the form of carbon taxes, while potentially a better idea than cap/trade absolutely goes against the dogma of the R's in congress who will do everything in their power to assure they get their way. The D's are afraid of even mentioning carbon taxes, although I'm betting a large number of them would support it over cap/trade but don't think for a minute it would be palatable across the isle so they don't even try.
Just as laptops and desktops aren't that much good without internet access, neither will this be.
I find this curious, as my desktop can be unplugged from the network. When its unplugged I still have access to a couple Tb of movies, music, games, etc on the HD. In fact I can install new games/etc with CD/DVD/BluRay. I can also create my own music, art, movies, edit photos, applications, etc.
The tablets generally are far more handicaped in this mode, as there isn't a marketplace for buying usb/sd cards preloaded with applications or music. Sure you could boot your PC and copy stuff to usb/sd, but that basically reinforces my point that PC's function far better without network connections. Plus, your not exactly storing a lot of movies in 8-32GB of space. Outside of maybe ebooks, you could probably run through all the content stored on a tablet in a matter of days.
That said, the 10" tablets excel at being the handy web surfing device sitting in the kitchen/living room (especially the touchpad with its inductive charging dock). Pick it up, poke in a search read the results put it back on the dock. Frankly, its not good at much else. Its two big to carry around all the time, and two small to use at home for watching movies/games/music. Same think with the e-ink kindles, they are rocking ebook readers, but not so hot at much else.
What I mean with lackluster on x86 etc is that I/O is still sequential bus limited, and even with DMA etc, the CPU STILL has to do some of the I/O shuffling gruntwork.
This discussion has come up in numerous places over the last few years and is basically false. The majority of the modern x86 peripherals have as much if not more of intelligence than channel processors. For example fiber channel and SAS boards from qlogic/emulex/etc have full blown processors on them running firmware that handles all of the fiber channel protocol and a large part of the FCP portions. Leaving the CPU's to do little more than specify via SCSI CDB's and target ids which data blocks get moved where. Once the operation(s) are complete the board interrupts a CPU. These boards maintain all the connections, and keep track of tens of thousands of simultaneous IOs. The CPU usage to transfer 3GB/sec to/from disk in our setup is less than 1% and a large portion of that is our application sending messages to-from the OS. Its the same with inifiniband, as the protocol is handled by the adapter, leaving the CPU to do little more than trigger the remote operations.
Combined with the fact that PCIe now includes peer to peer as part of the standard means that you can actually do IO between devices with out even the memory subsystem getting involved. This is how GPU's are doing SLI.
Anyway, I think the original discussion was more about how intel was intending to displace the RISC vendors, aka the power systems not the mainframes. Either way, I think my original point stands, as i'm betting the system your talking about is well into the 7 figure range, or roughly two orders of magnitude more expensive for what is probably only one order of magnitude faster than a single node in our cluster. As our application has nearly linear scaling for node counts in the few dozen range we are an example of an application that probably gets similar (if not greater) IO and processing performance out of cheap Intel hardware.
BTW: Texas Memory Systems makes some cool stuff, and systems like http://www.fusionio.com/products/iodrive-octal/ do a lot to move cheap intel hardware into places that traditionally required big iron.
but external I/O is.. lackluster compared to what a z10 can do.
Hardware support for BCD or decimal FP? Because x86 has had hardware BCD support since the 8086, and now you can do BCD with SSE. How may digits are your BCD values?
I'm also curious what your cumulative IOP/GB/sec numbers are..
We are pushing a little over 12GB/sec (yes bytes, and fully 1/4 of that is disk IO) through the PCIe buses on a dual socket westmere (including a fairly large amount of data transformation in memory), and that is the limit of the 4 adapters we have in the machine. There are slots for more, so it might do more. But once the new PCIe 3.0 sandy bridge machines come out we will probably upgrade the adapters, and put more of them in the machine.
This on a machine that costs about 1/2 the cheapest P710 Express configuration. At those prices you can't even begin to touch the big iron even if we have a dozen or so nodes.
Frankly, i've seen a lot of data centers time and time again, some guy who is talking about the IO requirements on his machine discovers when we drop an analyzer in the path that its only doing a few hundred MB/sec aggregate IO. They are transaction limited to disk, or latency limited between cluster nodes, etc..
Slashdot Mirror
I'm to lazy to double check, but mouse control ended up in doom after the doom 2 release (1.666?). I played a crapload of multiplayer doom my sr year in hs. I was the best out of maybe a dozen friends. Then I started college and stopped playing, until christmas break or some such. When we all got back together a couple friends from gtech totally kicked my backside because they had been playing doom 2 with the mouse in the labs. It took me maybe 5 hours to conclude I had to switch. The reason was simple (this predated mouse look), you could turn faster, and it made all the diffrence.
I didn't see anyone else mention this, but on windows and AIX, one of the reasons for using a binary log format is internationalization. Log messages are little more than application/facility id, log id, and parameters. The when the user displays the message the ids are looked up in a localization table and formatted according to the attached parameters.
$23.99 cheap knockoff
Cheap when compared with $110, but still totally crappy shirt for 2x what it should cost.
Still hasn't started transitioning their HP-UX, Nonstop, etc customers to something else. It generally takes a generation or two before all the lagards get on board a new arch. Heck, HP was still selling PA-RISC machines a couple years ago, long past the point where it was apparent the itanic was a dead end.
It seems that HP is intended to keep forcing intel to make the itanium forever, but they have to have a fallback plan. The question is, does HP want to pay for full development of a chip so complex it takes 10x the manpower to design for, or are they going to bring back something like PA-RISC or Alpha that goes fast, without to much effort. Their only other alternatives seem to be jumping on the x86 or POWER bandwagon. I might included sparc, but outside of fujitsu, that seems pretty dead too.
Which for anyone not playing quake was an absolutely fantastic CPU. I had one of the PR166 (aka 133Mhz, IIRC its was actually an IBM) ones, and it absolutely trounced my roommates P90 (which actually cost a little more), in everything. It was actually pretty amazing. Then there was quake, which was hand optimized for the pentium U-V pipeline arch and made heavy use of FP. The results was that in quake my PR166 @ 133Mhz was performing on par with the 90Mhz Pentium which cost about the same amount of money. I didn't understand the smear campaign back then, and I still don't. Everyone insisted on comparing the PR166 against the P166 which cost significantly more, and complaining when it didn't best it in one or two benchmarks. Dollar for dollar the PR166 kicked the crap out of anything Intel offered. In its worse case it was roughly equal to the equivalently priced pentium, but in its best case was equal to a processor that cost ~3x more.
The general consensus was that the cyrix had crappy floating point, but the cycle latencies were actually equal or better than the Pentium, what killed it was its inability to execute pentium scheduled FP code efficiently. I rolled a couple microbencmarks of my own just doing streaming multiplies and divides and the cyrix could actually beat the Pentium at the same clock rate when the code wasn't explicitly optimized for the Pentium (aka 486 scheduled FP was faster on the cyrix than the P).
Then there was the mystery of why Microsoft disabled the L2 CPU cache in NT when using a cyrix... Which is another whole discussion.
In all, the only real gripe I had about the CPU was its absolute need for good cooling. Without a good fan/heat-sink properly applied it would crash.
RS232 devices are not real "RS232", but implement "compatible 3/5-wire" serial communication.
Well, invariably a lot of applications don't need all the extra signal pins, things like carrier detect are pointless with a cabled null connection. The addition of FIFO's and CPU's that are millions of times faster also reduced the need for the DSR/DTR, RTS/CTS flow control. But none of this is really a problem. The really ugly problems come from the devices that are two cheap to use charge pump line drivers, and claim RS232 compatibility while only driving 5V.
All that said, a big portion of the advantage of RS232 on the PC has to do with the fact you can talk to COM1/2 on most pcs at a fixed IO port address (and hence one of the many reasons why USB converters aren't a replacement).
no character encoding, no protocol auto-detection, no data compression, no "real" error correction, so comparing it to modern interfaces such as ethernet, firewire or usb is a bit like comparing apples to oranges.
ethernet/usb/etc have compression in the protocol? Could have fooled me. The lack of autobaud is a weakness and probably the main failing of the protocol. More recent devices (aka lots of the USB serial converters) actually do have autobaud and it works pretty well.
The lack of error correction isn't a problem for RS232.
In a way this is an advantage too. RS232 data rates are so slow that its possible to get a very clean signal. Sure its also easy to have bad cables, or external interference on long runs. I've done enough programming with RS232 and more modern interfaces to say that in the end having error correction on the line doesn't do a damn thing for application level programs. That is because small error rates that are hidden by the error correction are rare. Invariably the problem is severe enough to require someone to go investigate why the application fails or is running slowly. Discovering you have a bad USB cable dropping a bit here/there resulting in 90% packet loss, is no different from discovering you have a cable flipping a few bits on your rs232 line and are retransmitting 90% of your packets. Simple devices, on short runs (think keyboards), work equally well on serial protocols without error correction (ps/2) as they do on ones with error correction (USB). For more complex systems the error detection, and retransmit logic needs to be pushed into the higher level protocols anyway. Adding a simple CRC on the end of a packet going down RS232 is incredibly easy and gives you a lot of protection.
I'm not necessarily arguing that we should be putting 4 serial ports on PCs, but removing the last one on a desktop machine so we can have 12 USB ports instead of 10 is silly. The weekly discussion on the ntdev mailing lists, or similar ones for linux, about getting the kernel debuggers working, invariably result in someone suggesting the developer take the machine apart and locate the unsoldered RS232 headers and soldering on a connector.
Its the KISS principal (something that many people on this board fail to understand). RS232 is so simple the entire hardware/software interface can be implemented in a handful of gates, and a few dozen lines of code. Plus, the PC 8250 interfaces one of the few things you can actually depend on when the proverbial crap hits the fan. Both windows and linux kernel debuggers run over RS232. There have been numerous attempts at making ethernet, firewire, usb interfaces, but invariably they die and boring old RS232 keeps on chugging.
Plus, basic rs232 type interfaces are everywhere in real life. From industrial machines, to the insides of a huge percentage of usb peripherals with simple USB to serial converters interfacing to the actual hardware.
Then there is the fact that you can run 50' rs232 cables..
Is that a lot of it comes from having the engineer on the factory floor talking to the machinist/whatever.
If you don't know where the manufacturing difficulties are, then you can't redesign it, and produce the next generation that is lighter/faster/cheaper/whatever.
Sitting in an ivory tower playing with CAD/simulations only gets you so far. Eventually you have to actually build it, its then that you discover that you design cannot be built, or it fails in some catastrophic manner. This happens far more than anyone is willing to admit.
The same is true of software, this year you teach a bunch of people how to create your product. Next year, they build their own without you. Now instead of those jobs being the next town over, they are in some foreign country where the cost of living is 1/1000th and you simply cannot compete.
Globalization is great, if your china/india/etc and have a surplus of labor. For everyone else, other than those that can exploit the foreign workers it sucks.
I can't believe no one has mentioned this yet!
But, before perl, what was Larry Wall famous for?
Winning the IOCCC, not once, but twice.
Makes you think...
Many common programming tasks require extensive pointer manipulation in C.
Pointer arithmetic, or pointer storage (aka linked lists?), or argument passing?
Frankly, I suspect you have been reading your old copy of K&R to much. Most modern (aka written in the last 20 years, by experienced developers) C rarely does pointer arithmetic. There isn't any reason, as the compilers/CPUs started being able to optimize the array syntax (var[offset]) to perform equivalently (if not faster) than similar pointer based code. When that happened the readability/debuggability/security aspects outweighed the slight performance difference of doing it the way K&R demonstrated in the 70's. The problem is that to many newbies listen to the old guys, talking about how great the K&R book is for learning C, and proceed to mimic many of the harmful tricks and styles in that book.
Bah, I cut the cable 7 or 8 years ago, primary because I refuse to pay for crappy programming with commercials.
I don't miss cable one bit, on the other-hand the ~10 channels I get over the air actually are pretty nice. I get 3 PBS's, and the large broadcast affiliates, which provide local news (for what its worth), and assorted other "entertainment".
Giving that spectrum to AT&T isn't going to do a darn thing to increase your bandwidth (shared medium with long haul transmission capabilities) and you can bet the telcoms will charge you for every byte you download from it.
All that said, there is also the quality issue. I have yet to see a single streaming "HD" video, that even approaches the quality of ATSC 1080i. Netflix looks great on a 19" screen. It looks horrible on a 42" much less a 60". Subjectively, I find their HD streams look slightly worse than a upscaled DVD, and that is with a 30Mbit internet connection. This doesn't mean I'm complaining about it, just that once in a while I like to see actual HD quality video. For that I flip on the ATSC receiver, stream a ripped title from the PC, or put an actual piece of media in the home theater stack.
Find something that excites you, is completely new to you, and doesn't have a million other people doing the same thing.
For me, that has been things like, finding a small microcontroller and writing a tiny OS to run on it (long before that became the cool thing to do).
Building a small embedded appliance, by designing the PCB, and a couple small pieces of code.
Writing a compression algorithm, using GPGPU.
A temp dependent overclocking utility.
Witting a web javascript UI toolkit to do overlapping windows & WIMP style programming.
The trick is to find something completely new, so your constantly learning something (be that a language, piece of hardware, environment, etc). Then you have to come up with something that hasn't been done on that platform before. Then when it gets boring, dump it. Doesn't matter if its finished or not, just go do something else that excites you. Often if you pick the right project, it will remain exciting well beyond the point where it is working. Even better, sometimes beyond the personal growth, if you post it to sourceforge, an app store, etc you will find others that are interested in it and it becomes a chance to earn a little $. Then in some cases one thing leads to another. Don't expect to get rich, or set unrealistic goals. In other-words reject ideas outright that seem like they might take more than a couple months. The idea is for this to be fun, not a second job. In the past it used to bother me, the dozens of 1/2 finished projects I started. Then I realized it was better that way. Now I don't struggle to finish something, if it gets boring, I just do something else. I still learn a crapload, and my cool geek friends think 1/2 finished partially working projects are just as cool as fully working ones. They see the potential. Plus, the amount of $ made when I do finish something is rarely more than the equivalent of a minimum wage job.
I will second this, I ported some stuff to webos recently. Now when i'm at work I can't wait to go home and screw with my app.
I agree with your points in general, but this stood out:
For example, backup tapes greatly benefit from compression, because they have relatively slow transfer rates to begin with
Uh, you know that current tape drives (T10k, 359x, even LTO) all have physical media transfer rates between 140 (LTO5) and 250MB/sec (3592E07)? With compression it possible to get over 350-600MB/sec (depending on drive & compression ratio) on all the current generation drives. So, yes compression helps, but the drives aren't slouches. In the end, even a modest library with a dozen drives probably has more bandwidth than most companies combined disk subsystems. The backup bottlenecks are almost always how fast can the changed data be sourced from the array. Most of the "enterprise" backup solutions have some disk stage component built into them now, that sources from multiple servers, and then writes the result to a single tape drive. The problem is that a lot of places fail to realize that they cannot just create a media server out of a random dell/HP/IBM machine, instead they need to attach extremely fast disk on the staging machine. Of course this problem is made worse by the fact that none of the major storage vendors see fit to sell a medium capacity disk (50-100T) with gigabytes of IO bandwidth for just a few thousand dollars. For that you have to look at the 3rd tier storage vendors.
Probably worth pointing out that compression will often actually improve disk IO.
Well, not really. If that were true then windows would probably enable folder compression by default. Besides latency issues that someone else pointed out, the overhead of doing something like updating 512 bytes in the middle of a file is significantly faster with an uncompressed file than a compressed one. Furthermore, streaming read/writes are where a the compressed filesystem gains advantages. In those cases the amount of advantage is dependent on the actual performance of the CPU's, compression ratios, and drives involved. Its also dependent on the question of whether there is a CPU sitting around idle. Anyway, the actual performance of a high speed algorithm like LZO (or LZS in the old days) has never really been much more than 2-4x a single hard-drive (and in some cases worse by similar factors). You should think about how the system performs when the compression ratio of the data is 1.2:1. Then consider that rarely was the compression ratio of a whole volume much greater than 2:1. Any advantages of compressed volumes were easily overcome with just basic software RAID0. Higher end RAID systems were often significantly faster than compression.
A lot of people are saying "I would fire the guy who writes his own x function". That is sort of a valid statement, but you have to consider that is also 99% of the problem with bloat. Say for example I want to md5 something. I could pull in a basic MD5 algorithm, slow but functional in a few hundred bytes. Want it faster? Then add some tables. Or you can just go with the really fast one built into openssl. The problem is you just pulled in another 1M+ of code you have no need for. Sure demand paging then turn around and removes it, but the page table entries, linker fixups, etc are still being created. Multiply that by a hundred or so libraries any non trivial application is using and, pretty soon your looking at a base VM size of a few tens or hundreds of MB.
There is also a lot of hidden functionality in applications today. Consider Unicode capable string functions, network communications code, etc. This is part of the joy of phone/tablet development. You can create an application without all the crap and get away with it.
In which case this makes perfect sense. There is an absolutely massive difference between recommending a spec for a developer machine and stating requirements for building the source.
Furthermore, there isn't any reason to be building on the "developers" machine anyway. That is _SO_ Microsoft... I worked for a company 15 years ago that cured me of that. Ever since, I always recommend build machines. That way you spend a bunch of money getting a fast disk and a lot of CPU's put it in the closet and then the compile speeds don't factor into the decisions on the developers desktop. It also provides a place to have a standard set of libraries/etc in order to get repeatable builds. Takes a little getting used to, but it turns out that most people accept that not everyone can have a 64 thread machine with 128G of ram on their desktop, and once it becomes apparent that not everyone is building at the same time, the speed advantages are readily apparent. Buy a new one every year or so, and the developers machines last longer too.
And people who pay attention to history, understand that is how the US got there too. I remember as a school child learning about Francis Cabot LowellWho "borrowed" the technology to build a power loom in the US and thereby allowing (with the cotton gin/etc) the US to become an exporter of textiles rather than cotton.
This complaint is about the Chinese investing $30 billion in solar energy subsidies. How much have Germany and the U.S. invested in green energy
Yes, and this isn't understood by many of the people in the US, who are busy complaining about Solyndra. Of course if you consider what $40B (not all solar), gets you in the US, vs $30B (all in solar) gets you in China. It doesn't really seem fair, besides being surgically focused (instead of a bunch of pie in the sky BS like much of the $40B), $30B in china goes to pay a lot more workers and build bigger factories than the equivalent sum in the US.
Frankly, I could care less about solar/etc, because the second power actually becomes a problem in the US (due to trade war with china, global coal ban, whatever) and we have a proper discussion, we will start building nukes.
I have a treo 650 from 2004/5. That is what passes for my cell phone. Its nearly indestructible, and its totally user serviceable, unlocked and hackable. I have swapped the battery, screen, keyboard, etc. The parts are becoming a little harder to find but there are still a lot of listings on ebay for complete functional ones for less than $20. Its also got a large selection of applications, Bluetooth, etc. In fact I recently upgraded my 12 year old toyota to a newer model which has voice activated Bluetooth, and the phone just paired right up. I also pay on average less than $10 a month for cell service. So its totally possible, to avoid the cell phone trap of a $50-$100 bill each month.
Personally, I suspect the iphone will be the next phone like this, simply because of its ubiquity. While a total PITA to replace a screen/battery/etc, the absolute number of them will assure a long life on ebay at reasonable prices. Anyone who knows how to unlock and crack the case will have a good supply of parts. Finding batteries will probably be fairly easy too, there are a bunch of 3rd party battery manufactures.
It's likely not to be the case, at least in the short term, hardware will absolutely require some shutdown time, to get to a stable standby state.
And the reinit time to resync the PCIe links, release an IP, etc..
We have similar functionality today in the form of S3 sleep which powers everything down but the RAM. Resuming requires all the drivers to wake their hardware and get it operational again.
What next a conservative that notices that cutting govt spending on teachers, etc in the middle of a (de/re)pression results in worse unemployment. Or that maybe trickle down economics has failed every singe time its been tried (not just in the US). Or that maybe giving large companies more cash in the form of reduced regulations, low interest rates, etc is a 2/3nd order stimulus and is worse than useless when large companies are sitting on cash stockpiles?
But, you know its all about party/dogma over country for a significant percentage of the elected representatives in congress. Otherwise we would actually have a discussion about cap/trade/etc. The problem is that "raising" taxes in the form of carbon taxes, while potentially a better idea than cap/trade absolutely goes against the dogma of the R's in congress who will do everything in their power to assure they get their way. The D's are afraid of even mentioning carbon taxes, although I'm betting a large number of them would support it over cap/trade but don't think for a minute it would be palatable across the isle so they don't even try.
Just as laptops and desktops aren't that much good without internet access, neither will this be.
I find this curious, as my desktop can be unplugged from the network. When its unplugged I still have access to a couple Tb of movies, music, games, etc on the HD. In fact I can install new games/etc with CD/DVD/BluRay. I can also create my own music, art, movies, edit photos, applications, etc.
The tablets generally are far more handicaped in this mode, as there isn't a marketplace for buying usb/sd cards preloaded with applications or music. Sure you could boot your PC and copy stuff to usb/sd, but that basically reinforces my point that PC's function far better without network connections. Plus, your not exactly storing a lot of movies in 8-32GB of space. Outside of maybe ebooks, you could probably run through all the content stored on a tablet in a matter of days.
That said, the 10" tablets excel at being the handy web surfing device sitting in the kitchen/living room (especially the touchpad with its inductive charging dock). Pick it up, poke in a search read the results put it back on the dock. Frankly, its not good at much else. Its two big to carry around all the time, and two small to use at home for watching movies/games/music. Same think with the e-ink kindles, they are rocking ebook readers, but not so hot at much else.
What I mean with lackluster on x86 etc is that I/O is still sequential bus limited, and even with DMA etc, the CPU STILL has to do some of the I/O shuffling gruntwork.
This discussion has come up in numerous places over the last few years and is basically false. The majority of the modern x86 peripherals have as much if not more of intelligence than channel processors. For example fiber channel and SAS boards from qlogic/emulex/etc have full blown processors on them running firmware that handles all of the fiber channel protocol and a large part of the FCP portions. Leaving the CPU's to do little more than specify via SCSI CDB's and target ids which data blocks get moved where. Once the operation(s) are complete the board interrupts a CPU. These boards maintain all the connections, and keep track of tens of thousands of simultaneous IOs. The CPU usage to transfer 3GB/sec to/from disk in our setup is less than 1% and a large portion of that is our application sending messages to-from the OS. Its the same with inifiniband, as the protocol is handled by the adapter, leaving the CPU to do little more than trigger the remote operations.
Combined with the fact that PCIe now includes peer to peer as part of the standard means that you can actually do IO between devices with out even the memory subsystem getting involved. This is how GPU's are doing SLI.
Anyway, I think the original discussion was more about how intel was intending to displace the RISC vendors, aka the power systems not the mainframes. Either way, I think my original point stands, as i'm betting the system your talking about is well into the 7 figure range, or roughly two orders of magnitude more expensive for what is probably only one order of magnitude faster than a single node in our cluster. As our application has nearly linear scaling for node counts in the few dozen range we are an example of an application that probably gets similar (if not greater) IO and processing performance out of cheap Intel hardware.
BTW: Texas Memory Systems makes some cool stuff, and systems like http://www.fusionio.com/products/iodrive-octal/ do a lot to move cheap intel hardware into places that traditionally required big iron.
but external I/O is.. lackluster compared to what a z10 can do.
Hardware support for BCD or decimal FP? Because x86 has had hardware BCD support since the 8086, and now you can do BCD with SSE. How may digits are your BCD values?
I'm also curious what your cumulative IOP/GB/sec numbers are..
We are pushing a little over 12GB/sec (yes bytes, and fully 1/4 of that is disk IO) through the PCIe buses on a dual socket westmere (including a fairly large amount of data transformation in memory), and that is the limit of the 4 adapters we have in the machine. There are slots for more, so it might do more. But once the new PCIe 3.0 sandy bridge machines come out we will probably upgrade the adapters, and put more of them in the machine.
This on a machine that costs about 1/2 the cheapest P710 Express configuration. At those prices you can't even begin to touch the big iron even if we have a dozen or so nodes.
Frankly, i've seen a lot of data centers time and time again, some guy who is talking about the IO requirements on his machine discovers when we drop an analyzer in the path that its only doing a few hundred MB/sec aggregate IO. They are transaction limited to disk, or latency limited between cluster nodes, etc..