Hacker News Reader

Comment by 6thaccount2 | Hacker News Reader

Why? It is fairly close to the metal and runs on hardware DESIGNED to be fast for transactions. IBM mainframes aren't even expressed in flops but some other unit designed to represent transactions per second.

Edit: googled it and they use MIPS (millions of instructions per second).

View on HN

Well, in the mainframe world, people don't typically measure in MIPS or FLOPS for day-to-day work. It's all about efficiency and throughput. We care about actual elapsed time, and resource consumption rather than some abstract benchmarking metric. Part of this is because a batch job will NEVER get 100% of the CPU, because it is sharing the system with so many other processes.

                                        ----TIMINGS (MINUTES)-----                          -----PAGING COUNTS---- 
  STEPNAME PROCSTEP    RC   EXCP   CONN       TCB       SRB  CLOCK          SERV  WORKLOAD  PAGE  SWAP   VIO SWAPS
  ENDES000             00  15522   2105  0.019965  0.000636    0.1        116946  BATCH        0     0     0     0

Elapsed time is the typical benchmarking metric, used, for example, by the language benchmarks game.

Not sure what "abstract metrics" are you referring to.

fyi

"Measurements of performance" https://www.ibm.com/support/knowledgecenter/en/SSGU8G_14.1.0...

"Latency and Throughput" https://www.oreilly.com/library/view/web-performance-tuning/...

I know what latency and throughput are. I am asking what "abstract metrics" previous commenter was referring to as opposed to these.

Thanks for the helpful background. I think what I said still stands though.

In the PC world, my computer has a certain number of FLOPS even though it has no impact on my day to day work where I care more about RAM and such.

Exactly because there are no public benchmarks.

What do you mean by "transactions" in this context? I don't think either COBOL or old IBM mainframes support software transactional memory (STM) as that's a fairly exotic technique that's mostly seen in the context of Haskell and the like, even though it does seem interesting as a model for concurrency.

Like user bin0 said below, a mainframe can do 30k to 1.1M transactions like wire transfers in a second.

They also have rediculously high up times and much higher security (probably mostly via obscurity).

Unfortunately, they're insanely expensive.

Probably more obscurity than actual security, in my experience. I once knocked off about 10k users off of a dev mainframe LPAR simply by running a SQL query (crashed DB2 and the underlying OS). With someone with more experience than I had, probably could have been exploitable. It was an accident, but it happened.

Mainframes weren't nearly as rock solid as their reputation in the 3 years of dealing with them that I had.

Mainframes were great at processes that need high IO.

I've not dealt with them in close to 20 years, so dont know how current x64 linux or Windows stacks line up.

Mainframes are hugely expensive. 20 years ago, entry level for the hardware was around $500k, IIRC. Dont think that even provided storage or software licenses. But, yeah, youve got one largely extremely reliable piece of big iron that can handle nearly all of your needs.

I assume the focus is on big businesses and banks that can afford those numbers.

Kind of like how KDB+ is so expensive as they're targeting a niche audience. Even though that is purely software.

I'm a little bit confused by the terminology here. What exactly is a "transaction", in a lower-level sense? What does it consist of? Is it pure CPU processing of one data structure to another? Is it shuffling things around in a (local? remote?) database? Is negotiating a transaction with another mainframe somewhere else over TCP?

It matters, because otherwise any kind of performance number is meaningless. If it's just CPU processing, then 1.1 million is not that much. If it's doing some sort of network handshake/transaction with other mainframes, then it's VERY impressive.

You tend to have two types of processing done in a mainframe, batch and online. Transactions usually refer to online work. In the old times, it used to be someone connecting in 3270 and issuing a bunch of "transactions" to bring up screens and perform various operations. Now, it would likely involve a web layer. The server part can be CICS for example, but they are others. Think of them as application servers. Proper batch jobs tend to perform even faster. There is a few reasons to that, one of them is the full integration of the systems (ie: the batch has "shared" memory access to the database, basically it's a big stored procedure).

Not in that sense, in the sense of "how many cart checkouts, wire transfers, other business logic transactions can I perform per unit x time?"

The concept of a transaction predates software transactional memory. It's a database term going back to when databases were invented.

Reply on news.ycombinator.com