6 ms·

> “I think there is a misconception about [COBOL]. A misunderstanding about it as far as it being old. Usually in technology we think because it is old it is ir

> “I think there is a misconception about [COBOL]. A misunderstanding about it as far as it being old. Usually in technology we think because it is old it is irrelevant,” he said. “But it’s still the fastest processing language out there.” 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.

lostmsu 7y ago
I'd be curious to see one. That statement seems extremely improbable.
- 6thaccount2 7y ago
  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).
  - lostmsu 7y ago
    Exactly because there are no public benchmarks.
  - 0815test 7y ago
    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.
    - bin0 7y ago
      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?"
    - 6thaccount2 7y ago
      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.
      - hermitdev 7y ago
        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.
        6thaccount2 7y ago
        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.
      - OskarS 7y ago
        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.
    - greglindahl 7y ago
      The concept of a transaction predates software transactional memory. It's a database term going back to when databases were invented.
  - Smoosh 7y ago
    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
    - lostmsu 7y ago
      Elapsed time is the typical benchmarking metric, used, for example, by the language benchmarks game. Not sure what "abstract metrics" are you referring to.
      - igouy 7y ago
        fyi "Measurements of performance" https://www.ibm.com/support/knowledgecenter/en/SSGU8G_14.1.0/com.ibm.perf.doc/ids_prf_041.htm https://www.ibm.com/support/knowledgecenter/en/SSGU8G_14.1.0... "Latency and Throughput" https://www.oreilly.com/library/view/web-performance-tuning/059600172X/ch04s02.html https://www.oreilly.com/library/view/web-performance-tuning/...
        lostmsu 7y ago
        I know what latency and throughput are. I am asking what "abstract metrics" previous commenter was referring to as opposed to these.
    - 6thaccount2 7y ago
      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.
- ethbro 7y ago
  Not particularly. It's analogous to saying 'A 60 year old language has better compilers than younger languages.' Which doesn't seem especially provocative.
  - lostmsu 7y ago
    It is quite provocative, considering the amount of activity over compiler's codebase. Which in case of COBOL is likely very close to 0.
    - lboc 7y ago
      Both IBM Enterprise COBOL [0] and GnuCOBOL [1] are in active development, and recent releases (September 2017 for both) appear to include support for the COBOL2014 standard. 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/PLCDetail.wss?synkey=B984385H82239E03&from=spf https://www-01.ibm.com/software/support/lifecycleapp/PLCDeta... [1] https://en.wikipedia.org/wiki/GnuCOBOL https://en.wikipedia.org/wiki/GnuCOBOL
tapland 7y ago
I think it mostly stems from IBM compiler optimizations for their mainframes (which is most of today's COBOL), and not the language itself. 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.
- randomerr 7y ago
  I've been able to get the same or very similar performance with modern languages that are a lot easier to debug. It just a matter of developers and management letting go of the old ways.
  - tapland 7y ago
    And the company willing to fork out ??? to migrate.
- kristopolous 7y ago
  Your day job, in 2019, is COBOL on OpenVMS? really? Tell me more. Is this new code? Are you using new hardware? Do you want my old alpha?
  - tapland 7y ago
    Been doing this for just over a year and mostly been doing new development where the need has just asrisen. 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!
    - HeWhoLurksLate 7y ago
      Shameless plug for r/homelab- if you're interested in doing server stuff at home, they're a great community to be a part of.
- kragen 7y ago
  You surely know more about COBOL than I do, but what about decimal arithmetic? I mean if the problem domain requires arithmetic correctly rounded to thousandths, with the operands loaded from fixed text fields and the results stored in fixed text fields, COBOL gives you that directly in the language, and presumably on a relatively efficient form. I don't know if using instructions like 8086 DAA and AAA is a win on today's CPUs, but surely avoiding the sequence of long divisions to convert from binary to decimal is a win (if what you're doing between input and output is, like, an addition and a multiplication by 1.0575, or something). Are you thinking that maybe some C++ template Decimal class with some integer parameters is going to beat GnuCOBOL on an amd64?
AnimalMuppet 7y ago
The fastest processing language... for what? 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...
- tasty_freeze 7y ago
  > The fastest processing language... for what? 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.
  - Tehdasi 7y ago
    I reckon the guy in the article was referring to COBOL basically having fixed sized data structures. Having all your data structures of a fixed size does allow for alot of optimizations that would otherwise not be available. However, you can make fixed size data structures in any language, and the benefits of this is somewhat moot with the large caches and fast CPUs (compared to IO) of modern computer systems.
  - Annatar 7y ago
    Actually it's very insightful since there are a lot of people who believe that a modern compiler can beat hand-written assembler code. Raising awareness about assembler and how the machine actually works equates to better working conditions for everyone, as we'll have more competent and knowledgeable colleagues then.

lostmsu 7y ago

I'd be curious to see one. That statement seems extremely improbable.

6thaccount2 7y ago
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).
- lostmsu 7y ago
  Exactly because there are no public benchmarks.
- 0815test 7y ago
  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.
  - bin0 7y ago
    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?"
  - 6thaccount2 7y ago
    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.
    - hermitdev 7y ago
      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.
      - 6thaccount2 7y ago
        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.
    - OskarS 7y ago
      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.
  - greglindahl 7y ago
    The concept of a transaction predates software transactional memory. It's a database term going back to when databases were invented.
- Smoosh 7y ago
  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
  - lostmsu 7y ago
    Elapsed time is the typical benchmarking metric, used, for example, by the language benchmarks game. Not sure what "abstract metrics" are you referring to.
    - igouy 7y ago
      fyi "Measurements of performance" https://www.ibm.com/support/knowledgecenter/en/SSGU8G_14.1.0/com.ibm.perf.doc/ids_prf_041.htm https://www.ibm.com/support/knowledgecenter/en/SSGU8G_14.1.0... "Latency and Throughput" https://www.oreilly.com/library/view/web-performance-tuning/059600172X/ch04s02.html https://www.oreilly.com/library/view/web-performance-tuning/...
      - lostmsu 7y ago
        I know what latency and throughput are. I am asking what "abstract metrics" previous commenter was referring to as opposed to these.
  - 6thaccount2 7y ago
    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.
ethbro 7y ago
Not particularly. It's analogous to saying 'A 60 year old language has better compilers than younger languages.' Which doesn't seem especially provocative.
- lostmsu 7y ago
  It is quite provocative, considering the amount of activity over compiler's codebase. Which in case of COBOL is likely very close to 0.
  - lboc 7y ago
    Both IBM Enterprise COBOL [0] and GnuCOBOL [1] are in active development, and recent releases (September 2017 for both) appear to include support for the COBOL2014 standard. 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/PLCDetail.wss?synkey=B984385H82239E03&from=spf https://www-01.ibm.com/software/support/lifecycleapp/PLCDeta... [1] https://en.wikipedia.org/wiki/GnuCOBOL https://en.wikipedia.org/wiki/GnuCOBOL

tapland 7y ago

I think it mostly stems from IBM compiler optimizations for their mainframes (which is most of today's COBOL), and not the language itself. 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.

randomerr 7y ago
I've been able to get the same or very similar performance with modern languages that are a lot easier to debug. It just a matter of developers and management letting go of the old ways.
- tapland 7y ago
  And the company willing to fork out ??? to migrate.
kristopolous 7y ago
Your day job, in 2019, is COBOL on OpenVMS? really? Tell me more. Is this new code? Are you using new hardware? Do you want my old alpha?
- tapland 7y ago
  Been doing this for just over a year and mostly been doing new development where the need has just asrisen. 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!
  - HeWhoLurksLate 7y ago
    Shameless plug for r/homelab- if you're interested in doing server stuff at home, they're a great community to be a part of.
kragen 7y ago
You surely know more about COBOL than I do, but what about decimal arithmetic? I mean if the problem domain requires arithmetic correctly rounded to thousandths, with the operands loaded from fixed text fields and the results stored in fixed text fields, COBOL gives you that directly in the language, and presumably on a relatively efficient form. I don't know if using instructions like 8086 DAA and AAA is a win on today's CPUs, but surely avoiding the sequence of long divisions to convert from binary to decimal is a win (if what you're doing between input and output is, like, an addition and a multiplication by 1.0575, or something). Are you thinking that maybe some C++ template Decimal class with some integer parameters is going to beat GnuCOBOL on an amd64?

AnimalMuppet 7y ago

The fastest processing language... for what? 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...

tasty_freeze 7y ago
> The fastest processing language... for what? 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.
- Tehdasi 7y ago
  I reckon the guy in the article was referring to COBOL basically having fixed sized data structures. Having all your data structures of a fixed size does allow for alot of optimizations that would otherwise not be available. However, you can make fixed size data structures in any language, and the benefits of this is somewhat moot with the large caches and fast CPUs (compared to IO) of modern computer systems.
- Annatar 7y ago
  Actually it's very insightful since there are a lot of people who believe that a modern compiler can beat hand-written assembler code. Raising awareness about assembler and how the machine actually works equates to better working conditions for everyone, as we'll have more competent and knowledgeable colleagues then.