Re: Linking Problem
- From: Russell <rws0203nospam@xxxxxxxxxxx>
- Date: Tue, 31 May 2005 12:33:43 -0500
mwojcik@xxxxxxxxxxx (Michael Wojcik) wrote in
news:d7hu2k02q33@xxxxxxxxxxxxxxxxx:
>
> In article <Xns9662B232731C1rws0203comcastnet@xxxxxxxxxxxxxx>, Russell
> <rws0203nospam@xxxxxxxxxxx> writes:
>>
>> If you did try to get by with compiling to an INT on one
>> system, and
>> running on another, note that INT's are quite slow.
>
> A rule of thumb used by some people who study performance is that on
> contemporary general-purpose processors, the worst case for micro-
> interpreted code (such as MF COBOL INT code, Java bytecode, UCSD P-
> System, etc) is about an order of magnitude performance hit. That
> would be for CPU-bound code with a broad instruction spectrum, and
> is due largely to cache penalties incurred by having to perform a
> table lookup for each byte.
>
> In practice, the actual performance cost for CPU-bound code is
> typically significantly smaller (because the instruction spectrum of
> typical code is smaller, CPU-bound code is often running in tight
> loops that are cache-friendly, interpreted code isn't often used for
> processing huge data sets that might stress the data cache, etc).
> It's more likely to be a factor of 3-5.
>
> With MF COBOL you have the option of compiling to INT, moving the INT
> to your target platform, testing it there, and then compiling it to
> native code, of course. This recompile-portable-form-to-native-form
> approach is similar to what the OSF was trying to do with ANDF - a
> good idea that never really got off the ground. JIT compilation is
> flashier, but all-at-once recompilation is a lot more efficient.
>
That is very true. This avoids the trouble of maintaining source
code on every platform. So long as you keep differences straight (path
names, delimiters, byte order, etc.), than copying the INT only can work
very well. An example of code that works very poorly on Intel Cpu's in INT
code is COMP-5. It flies in GNT, but is VERY slow in INT. At least last
time I checked.
Odd note - Barring the odd tight loop, I have noticed that the
performance gain a program gains from gnt seems to be proportional to the
size gain. A screen bound (character mode) GNT might be almost the same
size as the INT version. But unless you are sloppy, you might as well use
GNT everywhere. INT code does handle some sloppyness better, such as
uninitilized variables. I suppose the fact that MF has been dealing with
this format (INT code) for so many years pays off.
One trick I have been using, which would be handy when using INT code
to handle multiple platforms, without physically copying the source code,
is to check the linkage, and if the linkage is wrong (eg you expect 3
items, but got only two), display a few status items, such as compile date,
target operating system, etc. Using "plain" display without ADIS increases
the probablility that the user will see the message during normal
operation.
.
- References:
- Linking Problem
- From: hdumoulin
- Re: Linking Problem
- From: Richard
- Re: Linking Problem
- From: Wiggy
- Re: Linking Problem
- From: Russell
- Re: Linking Problem
- From: Richard
- Re: Linking Problem
- From: Russell
- Re: Linking Problem
- From: Michael Wojcik
- Linking Problem
- Prev by Date: SEARCH ALL
- Next by Date: Re: SEARCH ALL
- Previous by thread: Re: Linking Problem
- Next by thread: Dumb "figurative constant" rules
- Index(es):
Relevant Pages
|
