Excellent writeup. This sort of thing is why schlub requires users to specify the precision of calculations that they want to go into, so the interpreter/compiler can pick the correct numerical backend.
EDIT: For another bit of weirdness, recall that floating point addition is not always associative. Always consider adding up all your floats littlest to largest for maximum freshness.
But is Java’s BigDecimal really noticeably slower than Cobol’s? Benchmark in this article compares Java’s floats with Java’s BigDecimals, not Java’s BigDecimals with Cobol’s BigDecimals. Uniquesoft’s article also didn’t come to conclusion: they were migrating from mainframes to common x86 hardware.
I thought primary use of Cobol is legacy banking and business data applications, not rocket engines and physics simulations (unlike Fortran), so why performance of fixed-point numbers have such importance?
Python (and for that matter Java) do not have fixed point built in and COBOL does.
In order to get Python to do fixed point I needed to import the Decimal module.
Does this really matter? Moving features from core language to standard library is usually considered good thing.
In a related part of the article, it’s mentioned the systems in this are dealing with millions/billions of ops/second. any Decimal operation in Python requires at least 2 dict lookups because you have to pierce the instance attribute dict and class attribute dict to get to most operations.
That’s not to say you shouldn’t measure things, but I wouldn’t be surprised at order of magnitude differences here.
At $WORK, we’ve had to deal with similar sorts of math-related issues (order-dependent calcs and global rounding state make stuff pretty hard). What we end up doing is trying to isolate the math so we can work on the surounding code. So you have doMathStuff(blackBoxData). This let us clear the way for refactoring and cleanup around this.
I don’t know the COBOL FFI story, but if I were in charge of handling some legacy COBOL transition I would likely go a similar route. Ultimately the math is important, but a small/isolated part. So trying to replace the top layer of these aplications with more modern languages (and the tooling that comes with), and avoiding the math stuff would let us get some very nice advantages.
By the end, if you’ve isolated just the math, you could have a bunch of in-process COBOL VMs just running calculations, and your other tooling calling out to it via some pointers or w/e. And by that point you now have a stable foundation to actually replace with some custom C code or the like to replicate fixed point logic. Plus infrastructure to let you make your systems a bit more decentralized.
I bet the undercurrent is a lot of the COBOL machines are running tasks that are hard to parallelize simply because the tooling isn’t present. Hence the need for speed/one machine to run millions of ops a second.
Excellent writeup. This sort of thing is why schlub requires users to specify the precision of calculations that they want to go into, so the interpreter/compiler can pick the correct numerical backend.
EDIT: For another bit of weirdness, recall that floating point addition is not always associative. Always consider adding up all your floats littlest to largest for maximum freshness.
But is Java’s BigDecimal really noticeably slower than Cobol’s? Benchmark in this article compares Java’s floats with Java’s BigDecimals, not Java’s BigDecimals with Cobol’s BigDecimals. Uniquesoft’s article also didn’t come to conclusion: they were migrating from mainframes to common x86 hardware.
I thought primary use of Cobol is legacy banking and business data applications, not rocket engines and physics simulations (unlike Fortran), so why performance of fixed-point numbers have such importance?
Does this really matter? Moving features from core language to standard library is usually considered good thing.
In a related part of the article, it’s mentioned the systems in this are dealing with millions/billions of ops/second. any
Decimaloperation in Python requires at least 2 dict lookups because you have to pierce the instance attribute dict and class attribute dict to get to most operations.That’s not to say you shouldn’t measure things, but I wouldn’t be surprised at order of magnitude differences here.
At $WORK, we’ve had to deal with similar sorts of math-related issues (order-dependent calcs and global rounding state make stuff pretty hard). What we end up doing is trying to isolate the math so we can work on the surounding code. So you have
doMathStuff(blackBoxData). This let us clear the way for refactoring and cleanup around this.I don’t know the COBOL FFI story, but if I were in charge of handling some legacy COBOL transition I would likely go a similar route. Ultimately the math is important, but a small/isolated part. So trying to replace the top layer of these aplications with more modern languages (and the tooling that comes with), and avoiding the math stuff would let us get some very nice advantages.
By the end, if you’ve isolated just the math, you could have a bunch of in-process COBOL VMs just running calculations, and your other tooling calling out to it via some pointers or w/e. And by that point you now have a stable foundation to actually replace with some custom C code or the like to replicate fixed point logic. Plus infrastructure to let you make your systems a bit more decentralized.
I bet the undercurrent is a lot of the COBOL machines are running tasks that are hard to parallelize simply because the tooling isn’t present. Hence the need for speed/one machine to run millions of ops a second.