> I'm sure that an optimizing compiler can do an amazing job, but in this case > it was Enterprise COBOL vs handcoded Assembler. I have a hard time believing > that COBOL is faster than assembler in any scenario. Enterprise COBOL is our > 'main' programming language and I haven't seen it perform any optimization > worth mentioning (even with OPTIMIZE(FULL)). The current compiler still > generates virtually the same code as it's predecessors did many versions ago. > > Which means it is unforunate that Angel isn't able to post the code. > Something must be awfully wrong with the assembler code if it is twice as > slow as the Enterprise COBOL code...
so far everyone seems to be assuming that it is the assembly language "business logic" that is drastically slower. Sight unseen I would guess that has almost nothing to do with it. The thing with HLLs is that their startup costs are (typically) higher than assembly language programs, but once they are running they typically pull ahead. That's because the HLL program (once running) does almost no system services other than perhaps I/O. Lots (most?) of assembly language programs use system services (getmain/freemain, recovery etc) with some frequency and those system service calls can easily and very quickly dominate the pathlength for the entire application. The more reasonable comparison would be between the Cobol application and an LE conforming assembly language equivalent. CC
