Comment Re:Who the hell keeps moderating this guy up? (Score 1) 325
I have read many of the same books, or at least I have read books making similar points. However, they may be wrong.
Client/server architectures have some important weaknesses as well as important strengths. One of the big problems is the maintenance of processing logic on multiple client machines turns out to be rather more complex and time consuming than maintaining it on a single central box. The current move to web-based applications is motivated, at least in part, by the desire to reduce maintenance headaches by centralizing the storage of business logic. Secondly, executing business logic on the client makes the most sense when the data reside there. When the data reside in a central database, for example when there are several GB of data in an RDBMS, moving the data to the client to apply the business logic does not make sense. (On the other hand, entering the individual records that make up the contents of the database may well be best implemented by moving the business logic to the client so that the data can be validated before it leaves the client.)
Cleint/server architectures are contrained by network data transfer rates and usage. The more the data and the more the users, the poorer the performance will be at any given level of network bandwidth.
As to the value of mainframes in today's world. A couple of words have been bandied about in this conversation, "reliability" and "throughput" among others. Linux is approaching mainframe reliability and will, I expect, actually get that good in the not too distant future. After all, Linux is maintained and enhanced by a large group of folks who take bugs personally (if MS dealt with bugs that way, NT would be so good that Linux would still be the personal toy of Linus and a few interested hobbyists.)
Throughput is a different issue. IBM mainframes handle enormous volume because the system is architected for it from the ground up. Mainframes have multiple separate processors in them that are designed to handle a single function or closely related functions very well. These individual processors take their cues from the CPU but even the CPU is a different animal on a mainframe than on a PC.
An unfortunate consequence of common terms is that when a mainframe person uses the term "CPU" they mean something slightly different than a PC person means. While both devices execute "machine code" instructions, the common range of instructions is different in important ways. A PC CPU is a general purpose device that handles I/O, computations, branching, sound, DSP, etc. A mainframe CPU can do all that but usually does not. Rather a mainframe CPU acts more like a compute server and a traffic cop inside a network. The mains mainframes use to process massive I/O volume is for the CPU to direct a peripheral device to "handle it" and to let the CPU know when it is done. (PCs implementing DMA go part way down that path and performance improves if done right.)
This traffic cop behavior, supported by off CPU devices is what make a mainframe MIP profoundly different than a PC MIP. The PC instruction to move a bunch of data is actually a tight loop executed over and over in the CPU to move data a byte or a word at a time. On a mainframe it is a single instruction that supplies the peripheral processor the target location, the size of the data block and the target destination. The CPU has no other involvement with the process. So, while a PC CPU is performing the I/O, the mainframe CPU is moved on to other tasks.
Couple this with data paths that are much wider than that on a PC, and masive volume can be handled on a "single" machine.
Thoughtful readers will point out that I have described a network and I will agree. However, the network is all within a very short physical distance and has been designed as an integrated whole from the start. High performance is a natural consequence of the design.