4 ms·

A very practical question: I am language agnostic. Lots of people have commented about COBOL and FORTRAN performance for purely mathematical problems, given the

by 1996 7y ago

A very practical question: I am language agnostic. Lots of people have commented about COBOL and FORTRAN performance for purely mathematical problems, given the amount of man-hours that went into the libs used by these languages when computing resources were scarce. That caught my eye. Because for what I do, every little bit of performance matters. There are no hiring constraints - I will get whoever and whatever I need, as long as it can be shown to increase performance - mostly latency, but also speed of computation on given hardware. Can I expect practical gains in a COBOL implementation of mathematical algorithms? (mostly matrix inversion and multiplications, but not just that)

ecshafer 7y ago
I've done some programming in Fortran in school doing computational physics. From what I can tell it isn't necessarily that the languages are super fast, compared to any other compiled language. You can get similar speed out of Fortran as C or C++ by doing the normal performance conscious practices of not allocating a lot of memory during calculations, optimizing loops, etc. Fortran has a lot of scientific packages that have been optimized very heavily, and those are linkable from other language, that is whay Scipy in Python is essentially. The Cobol I have touched isn't really that optimized I think, mostly just business code. But its fast due to no abstractions and being compiled. I don't think you would get gains from Cobol per se, and it might not be worth it compared to just writing C or C++ in a high performance manner.
- cygx 7y ago
  Fortran as a language had some advantages over C for high-performance numeric code (eg more restrictive aliasing rules or stack-allocated variable-length arrays). C99 addressed this.
  - pjmlp 7y ago
    C99 kind of addressed it, unless one manually takes the effort to properly place restrict in the correct places, and not mistakenly misuse it (possibly triggering UB), it won't match what optimizing Fortran compilers are capable of without any additional effort from the programmer.
    - 1996 7y ago
      Thanks. Your answer and ecshafer point me to start evaluating Fortran.
    - cygx 7y ago
      But note that that as far as I'm aware, Fortran compilers will happily miscompile code that breaks the aliasing assumptions as well. No matter which language you use, it's the responsibility of the programmer to not break these invariants, the main difference being that Fortran doesn't force you to type out `restrict` first.
      - pjmlp 7y ago
        In Fortran there aren't aliasing assumptions as in C, given that they are forbidden by the type system.
        cygx 7y ago
        It's forbidden by the language standard, hence compilers assume no aliasing occurs, but it nevertheless may do so due to 'non-conforming' code. In the words of the g77 manual: > Essentially, compilers are promised (by the standard and, therefore, by programmers who write code they claim to be standard-conforming) that if they cannot detect aliasing via static analysis of a single program unit's EQUIVALENCE and COMMON statements, no such aliasing exists. In such cases, compilers are free to assume that an assignment to one variable will not change the value of another variable, allowing it to avoid generating code to re-read the value of the other variable, to re-schedule reads and writes, and so on, to produce a faster executable. > [...] > Unfortunately, there is no way to find all possible cases of violations of the prohibitions against aliasing in Fortran code. Static analysis is certainly imperfect, as is run-time analysis, since neither can catch all violations. (Static analysis can catch all likely violations, and some that might never actually happen, while run-time analysis can catch only those violations that actually happen during a particular run. Neither approach can cope with programs mixing Fortran code with routines written in other languages, however.) Like in C, it will result in undefined behaviour (though the Fortran spec doesn't use the term).
zokier 7y ago
I think the one (and only?) neat trick that COBOL has is supporting decimal datatypes as first-class citizens, which makes it very convenient for monetary stuff and other business related things where you don't want to have 0.1+0.2=0.30000000000000004 Of course (IBM) mainframes and CICS have some other tricks in their sleeves, but those are bit higher level things and probably not relevant for number crunching as such. On commodity hardware I wouldn't expect COBOL code to perform particularly well compared to e.g. C (or indeed, FORTRAN).

by 1996 7y ago

ecshafer 7y ago

I've done some programming in Fortran in school doing computational physics. From what I can tell it isn't necessarily that the languages are super fast, compared to any other compiled language. You can get similar speed out of Fortran as C or C++ by doing the normal performance conscious practices of not allocating a lot of memory during calculations, optimizing loops, etc. Fortran has a lot of scientific packages that have been optimized very heavily, and those are linkable from other language, that is whay Scipy in Python is essentially. The Cobol I have touched isn't really that optimized I think, mostly just business code. But its fast due to no abstractions and being compiled. I don't think you would get gains from Cobol per se, and it might not be worth it compared to just writing C or C++ in a high performance manner.

cygx 7y ago
Fortran as a language had some advantages over C for high-performance numeric code (eg more restrictive aliasing rules or stack-allocated variable-length arrays). C99 addressed this.
- pjmlp 7y ago
  C99 kind of addressed it, unless one manually takes the effort to properly place restrict in the correct places, and not mistakenly misuse it (possibly triggering UB), it won't match what optimizing Fortran compilers are capable of without any additional effort from the programmer.
  - 1996 7y ago
    Thanks. Your answer and ecshafer point me to start evaluating Fortran.
  - cygx 7y ago
    But note that that as far as I'm aware, Fortran compilers will happily miscompile code that breaks the aliasing assumptions as well. No matter which language you use, it's the responsibility of the programmer to not break these invariants, the main difference being that Fortran doesn't force you to type out `restrict` first.
    - pjmlp 7y ago
      In Fortran there aren't aliasing assumptions as in C, given that they are forbidden by the type system.
      - cygx 7y ago
        It's forbidden by the language standard, hence compilers assume no aliasing occurs, but it nevertheless may do so due to 'non-conforming' code. In the words of the g77 manual: > Essentially, compilers are promised (by the standard and, therefore, by programmers who write code they claim to be standard-conforming) that if they cannot detect aliasing via static analysis of a single program unit's EQUIVALENCE and COMMON statements, no such aliasing exists. In such cases, compilers are free to assume that an assignment to one variable will not change the value of another variable, allowing it to avoid generating code to re-read the value of the other variable, to re-schedule reads and writes, and so on, to produce a faster executable. > [...] > Unfortunately, there is no way to find all possible cases of violations of the prohibitions against aliasing in Fortran code. Static analysis is certainly imperfect, as is run-time analysis, since neither can catch all violations. (Static analysis can catch all likely violations, and some that might never actually happen, while run-time analysis can catch only those violations that actually happen during a particular run. Neither approach can cope with programs mixing Fortran code with routines written in other languages, however.) Like in C, it will result in undefined behaviour (though the Fortran spec doesn't use the term).

zokier 7y ago

I think the one (and only?) neat trick that COBOL has is supporting decimal datatypes as first-class citizens, which makes it very convenient for monetary stuff and other business related things where you don't want to have 0.1+0.2=0.30000000000000004 Of course (IBM) mainframes and CICS have some other tricks in their sleeves, but those are bit higher level things and probably not relevant for number crunching as such. On commodity hardware I wouldn't expect COBOL code to perform particularly well compared to e.g. C (or indeed, FORTRAN).