4 ms·

What would prevent, in your opinion, to make some changes to current commodity hardware architectures (say, x64, arm...) to allow for mainframe-like scalability

What would prevent, in your opinion, to make some changes to current commodity hardware architectures (say, x64, arm...) to allow for mainframe-like scalability and reliability ? As per the article, how is the jitted/interpreted world of languages so bad ?

ianai 4y ago
ECC bring the norm and better error handling all around. OSes that better handle memory and uptime. Possibly something like a user session being accessible from allowed terminals and applications that call for that. Think hotel front desk staff or anyone public facing who move from desk to desk.
- User23 4y ago
  That ECC isn’t entirely standard is shameful.
- neverartful 4y ago
  There's far more to reliability than ECC. What if a processor/CPU goes bad in an x86 server while running? You have to take the server down, replace it, and bring it back up. IBM mainframes allow for processor replacements while it's running. I think it's the same with memory. IIRC, in the mainframe world IBM has processor and RAM packaged together as a 'book' and it may be the book that can be hot swapped. Hopefully someone more knowledgable can clarify.
  - rbanffy 4y ago
    A mainframe reminds me more of a cluster of specialised machines networked over ridiculously fast interconnects and purpose-specific networks that host those specialised machines. Some functionality of those specialised machines is exposed to user programs that can delegate some processing to these smart peripherals, offloading things like allocating blocks in the filesystem and letting the boxes that run your used code focus on running it without ever being disturbed with servicing network or disk interrupts.
froh 4y ago
patents, tongue in cheek... on a more serious note yagni: for most workloads you simply don't need the dependability and Xeon has caught up sufficiently for most workloads. however if your business depends on less than 5 minutes of unplanned downtime per year you need stacks designed for faul operational subsystems, i.e. subsystems which don't just detect faults and halt, but which gracefully handle many faults with a short degradation but no failure. and that's not only hard to master it's also plastered with IBM patents. wrt the jit/interpreted world my personal take is that silicon vendors are very happy about it. very few organisations feel the pain to an extent they innovate things like golang... and once they are in the business of selling compute power (as cloud service provider), there goes their motivation to create a sexy cobol.
bayindirh 4y ago
I'd say cost (of research, implementation and resulting product ). The additional hardware both in silicon and on PCB is massive to enable these kinds of reliability numbers. I played with some higher end HP servers back in the day, which allowed hot-swapping RAM carriers to maximize uptime. The construction on mechanical, electrical and software was much more sophisticated to enable these features. Which made the systems bigger, somewhat noisier and harder to maintain in a sense. When everybody is moving towards more cattle-like systems, and the behemoths like HPC doesn't care about reliability in the worker nodes (we just re-schedule the job, no biggie), that kind of reliability is not wanted by the people, in most sectors, and this low demand doesn't make the capabilities worthy to pursue. Also, there are system dynamics which affect operations profoundly. Your normal server boots in 5 minutes tops from power to "all services are ready to serve". Your run off the mill SMP server needs 15 minutes. A mainframe is never expected to be shut down, and if it's ever turned off, it's at least an hour required to spin that thing back up. We're talking about machines which have small "guns" inside to physically sever power lines in an emergency (sorry I can't find the story I've read about moving a datacenter hence turning of the IBM mainframes, however a related reference can be found at [0]). The JIT/Interpreted languages of the day were really bad. Java was heavy, other languages were slow. Today's JIT/Interpreted languages are fast enough, because the VMs running these have been optimized heavily, and the processors allows these VMs to run at much faster speeds because of available instructions, available memory and system interconnect speed at every level and interface. So the evolution of JIT and interpreted languages is a matter of chicken and egg. Hardware enabled both faster speeds and technology to write better VMs and optimize them further. [0]: http://www.catb.org/jargon/html/B/Big-Red-Switch.html http://www.catb.org/jargon/html/B/Big-Red-Switch.html

ianai 4y ago

ECC bring the norm and better error handling all around. OSes that better handle memory and uptime. Possibly something like a user session being accessible from allowed terminals and applications that call for that. Think hotel front desk staff or anyone public facing who move from desk to desk.

User23 4y ago
That ECC isn’t entirely standard is shameful.
neverartful 4y ago
There's far more to reliability than ECC. What if a processor/CPU goes bad in an x86 server while running? You have to take the server down, replace it, and bring it back up. IBM mainframes allow for processor replacements while it's running. I think it's the same with memory. IIRC, in the mainframe world IBM has processor and RAM packaged together as a 'book' and it may be the book that can be hot swapped. Hopefully someone more knowledgable can clarify.
- rbanffy 4y ago
  A mainframe reminds me more of a cluster of specialised machines networked over ridiculously fast interconnects and purpose-specific networks that host those specialised machines. Some functionality of those specialised machines is exposed to user programs that can delegate some processing to these smart peripherals, offloading things like allocating blocks in the filesystem and letting the boxes that run your used code focus on running it without ever being disturbed with servicing network or disk interrupts.

froh 4y ago

patents, tongue in cheek... on a more serious note yagni: for most workloads you simply don't need the dependability and Xeon has caught up sufficiently for most workloads. however if your business depends on less than 5 minutes of unplanned downtime per year you need stacks designed for faul operational subsystems, i.e. subsystems which don't just detect faults and halt, but which gracefully handle many faults with a short degradation but no failure. and that's not only hard to master it's also plastered with IBM patents. wrt the jit/interpreted world my personal take is that silicon vendors are very happy about it. very few organisations feel the pain to an extent they innovate things like golang... and once they are in the business of selling compute power (as cloud service provider), there goes their motivation to create a sexy cobol.

bayindirh 4y ago

I'd say cost (of research, implementation and resulting product ). The additional hardware both in silicon and on PCB is massive to enable these kinds of reliability numbers. I played with some higher end HP servers back in the day, which allowed hot-swapping RAM carriers to maximize uptime. The construction on mechanical, electrical and software was much more sophisticated to enable these features. Which made the systems bigger, somewhat noisier and harder to maintain in a sense. When everybody is moving towards more cattle-like systems, and the behemoths like HPC doesn't care about reliability in the worker nodes (we just re-schedule the job, no biggie), that kind of reliability is not wanted by the people, in most sectors, and this low demand doesn't make the capabilities worthy to pursue. Also, there are system dynamics which affect operations profoundly. Your normal server boots in 5 minutes tops from power to "all services are ready to serve". Your run off the mill SMP server needs 15 minutes. A mainframe is never expected to be shut down, and if it's ever turned off, it's at least an hour required to spin that thing back up. We're talking about machines which have small "guns" inside to physically sever power lines in an emergency (sorry I can't find the story I've read about moving a datacenter hence turning of the IBM mainframes, however a related reference can be found at [0]). The JIT/Interpreted languages of the day were really bad. Java was heavy, other languages were slow. Today's JIT/Interpreted languages are fast enough, because the VMs running these have been optimized heavily, and the processors allows these VMs to run at much faster speeds because of available instructions, available memory and system interconnect speed at every level and interface. So the evolution of JIT and interpreted languages is a matter of chicken and egg. Hardware enabled both faster speeds and technology to write better VMs and optimize them further. [0]: http://www.catb.org/jargon/html/B/Big-Red-Switch.html http://www.catb.org/jargon/html/B/Big-Red-Switch.html