I thought this comment was born from naivety or bias, but after reading up on it a little further, it appears that it's true or close to true for many cases.
I do COBOL mostly in OpenVMS and only tinker with IBM in the weekends but it would be cool to see how it performs under the same circumstances compared to other languages.
We run Itanium (exciting that the first OpenVMS X86 boot was recently) and when/if I can afford a house it's going to have plenty of hard toys!
Edit: googled it and they use MIPS (millions of instructions per second).
----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 0Not sure what "abstract metrics" are you referring to.
"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/...
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.
They also have rediculously high up times and much higher security (probably mostly via obscurity).
Unfortunately, they're insanely expensive.
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.
Kind of like how KDB+ is so expensive as they're targeting a niche audience. Even though that is purely software.
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.
It's analogous to saying 'A 60 year old language has better compilers than younger languages.'
Which doesn't seem especially provocative.
Not perhaps in the same league as more fashionable languages, but certainly a fair distance away from 'close to 0'.
[0] https://www-01.ibm.com/software/support/lifecycleapp/PLCDeta... [1] https://en.wikipedia.org/wiki/GnuCOBOL
First, it's never going to be faster than assembly on the same machine. That is not possible.
Second, I bet it's not faster than Fortran at matrix multiplication. (And anyone who tries to do matrix multiplications in COBOL should be barred from touching a keyboard for the rest of their life.)
What it may be the fastest at is certain business calculations. And it may be the fastest at them because they are traditionally carried out in fixed-point arithmetic. IIRC (and I may not), some mainframes had specific instructions/opcodes for fixed-point math. If COBOL uses those, and other languages don't, then COBOL could in fact be the fastest... at fixed-point math calculations. That's still a long way from "the fastest processing language", though.
The claim sounds like someone has mistaken their little corner of computing for the whole universe...
It seems pretty clear from context that it means for doing report generation and accounting things that COBOL is known for, not for LINPACK.
> it's never going to be faster than assembly on the same machine.
You are being unhelpfully pedantic. It is not insightful to say an optimal assembly program is going to be at least as fast as a compiler for a higher level language.
How can that happen? One reason is choice of algorithms -- the same reason why two programmers using the same language to complete the same task can produce remarkably different results.
Another reason is profile-driven optimization -- in theory the assembly language programmer can do this too, but the effort of restructuring lots of handwritten code is too painful. Yes, it is done sometimes (eg, different inner loops for video codecs for different versions of x86 cpus).
Likewise, optimizers and superoptimizers understand the pipeline quirks of specific processors better than most people writing assembly language for x86-type processors and can produce better results.
The question ‘fastest at what’ is right there in the original quote - processing. Assembly isn’t commonly considered a ‘processing language’ and in the context processing is a term of art for the kind of batch processing tasks cobol was designed for.
Even that aside, we all ‘know’ assembly is the fastest. It’s a given. Nitpicking comments like that betrays a hostile attitude and lack of generosity of spirit. We shouldn’t have to post pages if caveats and justifications and hedging for a comment like that.
Attacks like this come across as intellectual grandstanding and aren’t actually contributing anything of value.
So I thought it was a reasonable criticism of an overly broad or at least very ambiguous assertion, regardless of its motivation. It’s quite common for the best arguments against an argument to come from people who are hostile to it for whatever reason. More carefully defining the scope of things where we would expect COBOL to get top performance marks would make the conversation far more informative and productive.
As for assembly, there is now a broad class of problems for which CPU assembly is far from the fastest solution, because GPUs are faster. Even on the CPU, there is a widespread (but usually false) belief that compilers beat expert assembly programming. So perhaps to you it's a vacuously true statement that adds no useful information, I read it as rebutting a belief many readers may really have (though, unfortunately, only as a bare assertion.)
I think it's unreasonable to expect every comment about every bit of technology, old or new, discussed on HN to come with pages of preamble, caveats and definitions of terms.