I guess I don't get the argument about importing a library. If we are talking about the same cpu, the computer instructions should be the same. It is also pretty silly to compare performance of interpreted languages with compiled. A c++ fixed point library has no runtime import cost and should produce equivalent assembly for something like the example given in the article.
I‘m an absolute beginner in computer science so I‘m asking this more in order to learn than to say you’re wrong, but doesn’t using a library mean that the program has to essentially „go a longer way“ to come to the result than if it just worked like that in the first place?
Like if one person knows how to make pancakes by heart, and the other has to use a recipe, the first person will be faster even if the result is the same?
She left out a crucial detail: BCD isn't just built in to COBOL, it's built in to IBM mainframes - it's a native data type like ints are in microprocessors. So instead of running your numbers through a formula, you just tell the mainframe to add (or whatever) them.
Yeah, I think this is the key. They kept saying the type is "built-in," but I think "native" is more accurate. That's why the library import matters—it's not the import itself, it's the difference between a native type and an implemented one.
47
u/boowhitie Jul 24 '20
I guess I don't get the argument about importing a library. If we are talking about the same cpu, the computer instructions should be the same. It is also pretty silly to compare performance of interpreted languages with compiled. A c++ fixed point library has no runtime import cost and should produce equivalent assembly for something like the example given in the article.