Hacker News Reader

Comment by gaius | Hacker News Reader

The simple answer is that you have to have a consistent view of the world. Let's say that 100 Linux boxes in a cluster == 1 mainframe. Let's also say you're a bank. Someone connects to node 1 and makes a withdrawal from a joint account, and someone simultaneously makes a withdrawal from the same account on node 100. How do you check they haven't gone over their overdraft unless you can serialize those transactions? And if you can, and make it scale, congratulations: you're now where IBM was in the 70s'.

It's pointless to invoke the almighty Google; they simply don't deal with problems in this class.

View on HN

> It's pointless to invoke the almighty Google; they simply don't deal with problems in this class

FWIW, I worked at a major bank (top 5 in the U.S.) and listened in on several discussions between their top tech guys. As mentioned in other comments, their number one worry was the supply of COBOL coders.

They were terrified of Google and/or Paypal and what would happen if one of those companies got serious about competing in the banking arena. Most of the top architects _knew_ that it was possible to build a bank on a huge cluster of servers. They also knew that there was no way an existing bank could build the infrastructure and software while also maintaining their existing infrastructure.

Apparently PayPal isn't in technologically fantastic shape either. Word on the street is that they still have their core offering written in C using a CGI interface.

C? I guess that only puts them 30 years ahead of the banks, then...

With good unit testing C is very robust and also much cheaper in hardware footprint.

I wasn't as much bashing C as I was the use of CGI. Most of the time when C is paired with CGI it's a pretty good indication that the code is chock full of memory leaks.

If you are using CGI, then those memory leaks will be short lived, limited to one request.

Fork is still expensive. It is not sane to fork per request.

I would love to see some startup disrupt the banking industry.

Banks are actually kind of a bad example for needing synchronized processing. Banks settle transactions pseudo-asynchronously in batches. While they adjust your "available balance" as well as they can, AFAIK, transactions are officially settled in the old school, nightly batch.

Even then, there are consistent, synchronous databases that run on Linux clusters. Oracle RAC and Sybase ASE come to mind. Linux also supports hardware NUMA implementations, which allow single system image software. An emulation layer could run on top of NUMA hardware.

I am very experienced with RAC and its predecessor OPS. It really is nowhere near as performant or reliable or scalable or manageable as a mainframe. Which is not to say it's not "good enough" for many serious, real-world workloads, of course it is. But you're comparing a Toyota pickup to a JCB earthmover.

I'll definitely yield to your experience. What exactly makes the mainframes so much more capable? How does it compare to something like an SGI Altix cluster with 2048-core / 16TB single system image capacity?

The mainframe is built from the ground up for transaction processing. Have a look around Wikipedia for terms like: CICS, IMS, TPF, Sysplex, WLM. Everything, the hardware, the kernel, the rest of the OS, the programming model, the languages - all for this. It has no pretence of being a general-purpose computing platform.

The mainframe would suck for what you'd use the Altix for, e.g. weather forecasting. The Altix has a lot of processes that want to work on a common dataset, but it would grind to a halt if you tried to use its interconnect to serialize transactions.

Exactly what makes it so much more useful for transaction processing? I'm looking at these things you suggested, but how does CICS compare to something like BEA Tuxedo? Of course there are no benchmarks or talk of performance out in the open on the web because I'm sure their licensing agreements forbid that.

Do mainframes have some kind of crazy low-latency or high bandwidth bus that something like the Altix is missing? It appears they use similar hardware architectures, at least from a high level: super high speed modular backplanes with blade servers that form a single system image. The NUMALink 5 is stated as having 15GB/s of bandwidth (7.5GB/s in each direction) with a ~1µsec latency.

A mainframe is to transaction processing as a GPU is to 3D graphics. Does that make sense?

No, you are being extremely vague. A GPU only performs well at executing a small set of mathematical instructions in a very specific, ultra-parallelized model against limited sets of data. They are not Von Neumann machines. A mainframe runs business software on general purpose CPUs with a normal memory model. It wasn't long ago that Macs and IBM mainframes shared the same CPUs. Yes, they support virtualization in hardware, but so do cheap Intel processors now. They appear to be architecturally no different than large SMP boxes. Please enlighten me on the key hardware differences that make them so apt for transaction processing.

Heh, I suggest you do a little reading around the architecture and the way SAPs interact with the main processor(s).

Or we can just say that all languages that are Turing complete are equivalent...

Aging Mainframe Hardware is horribly slow. A fast 5,000$ server built today (Raid of SSD etc) is significantly more powerful than any Mainframe built prior to 1998. But Mainframe Software is far more efficient than anything built for a modern PC.

PS: I suspect a large part of this is the mindset and experience of the people building the software. Well written Java code can be about as fast a well written COBOL code, but the average Java system is horribly inefficient.

In floating point, yes you are entirely correct. But that old mainframe'd show you a thing or two about I/O.

I respectfully disagree. The only place they come close is a late 90's huge disk arrays, but random access to SSD arrays are amazing and once you start looking at things like L2 cache bandwidth old mainframes start looking anemic.

Edit: An 1980 IBM 3081 could access up to 32 megabytes of main memory. A 5400-series "Harpertown" can have 24 megabytes of cache. So Modern CPU cache memory vs Mainframe main memory is not an unfair comparison. But that's just overkill the real shocker is 3081 had less bandwidth to it's registers than many modern computers have to it's local network. (It was below 40MHz and consumed 23 kilowatts of power).

PS: Feel free to post some actual numbers.

Why do you keep comparing old mainframes to current tech? Why not compare current mainframes to current tech -- its like those people who try and compare the java of 1998 with the C of today (you know "jvm takes minutes to start, and has x, y and z gc issues...").

Mainframes from IBM are under constant revision and update, just like server tech.

Because they are still being used. People think they need to replace an old mainframe with a cluster but that's just not true. Also, large modern day mainframes have become distributed systems so while you may still need a cluster you are already using one.

PS: We live in an age of horrable custom software, sitting on a monstrous stack of terrible commodity software. If you spend a noticeable amount of time waiting on a modern computer system it's really just a software problem. (Wait you actually want to use XML?) But, often upgrading the hardware is really the best option.

I know that Google Checkout isn't a "real" financial institution but surely, I'd think those problems were of the same class - perhaps it's just that they don't have to worry about legacy problems (yet).

Google Checkout backs onto a payment processing gateway. Google isn't a bank!

Reply on news.ycombinator.com