Newsgroups: comp.lang.apl
Path: watmath!watserv2.uwaterloo.ca!torn!spool.mu.edu!howland.reston.ans.net!wupost!csus.edu!sfsuvax1.sfsu.edu!vpcsc4
From: vpcsc4@sfsuvax1.sfsu.edu (Emmett McLean)
Subject: Re: Implementation of forks in C
Message-ID: <1993Jun1.081417.24005@csus.edu>
Sender: news@csus.edu
Organization: San Francisco State University
References: <1993May28.040559.24278@csus.edu> <1738@kepler1.rentec.com>
Date: Tue, 1 Jun 1993 08:14:17 GMT
Lines: 63

In article Andrew Mullhaupt writes:
>In article Emmett McLean writes:
>
>Notice that translating code from J to C (but using
>the J functions in the source) does not guarantee
>improved performance.
>
>I should hope the reverse: if the J interpreter is anything worth bothering
>with then it should be able to call the functions as fast as you can. For
>anything worth timing, there should be no advantage to calling the J
>functions from C over calling them in J. The thing that C should be
>useful for is providing things which are not convenient J functions.

 The results I posted showed the transliterated J, coded in C, running
 slower than the interpreted J.

>As for using J functions as a prepackaged C language extension, I suppose
>that this is one way to avoid writing C despite a requirement for a C
>program, but you will not escape the larger limitations of a fixed set
>of large scale primitives - you end up with the same dead end as trying
>to do everything in a large scale language and the workarounds are harder
>to read. Sounds like a bad bargain, since you're going to end up doing mostly
>J programming in C (which should be less pleasant than J programming in J)
>and you still have to add the bits of C required for performance.

 I agree.  Programming J in C is not nearly as pleasant as
 programming J in J.  (The hardest part of writting the transliterated 
 code, BTW, is in allocating memory. If this were not the case,
 one could make a pretty good argument for the modularity, reusablity
 of code, and nice control structures of transliterated programs.)

>So if translating J into C is done for the sake of performance, then it
>almost certainly is the wrong problem to solve: if J code doesn't run
>at very close to full bandwidth interpreted by J then the J interpreter
>is seriously lame and speeding it up should be your first priority. Taking
>some J programs and translating them into C only speeds up those programs,
>(if at all) and this is not as good as speeding up the interpreter,
>since that wll speed up all future (similar) J programs as well.
>
 Isn't for speed. Its for a more user friendly implementation of the
 language. (Since this can be implemented in J one might say the 
 principle benefit is opaqueness.)

>This is a general situation with scientific interpreters. When they do 
> something as a primitive operation but _slowly_, then you scream at the
> pinheads who maintain the interpreter until they fix it. When necessary,
> you provide code that goes fast and help them integrate it into their
> interpreter. So this means that the thing that makes interpreters with
> large scale operations are slow, it is because the set of large scale
> operations does not adequately provide for a good implementation of an
> algorithm. In this case there is little to be gained by getting a different
> spelling for the same primitives. What you need is components which were
> not there in the set of interpreter primitives; and it stands to reason
> that they are not convenient in a new spelling of the old primitives
> if they were not convenient in the interpreter itself.

  Enhancing the interpreter is beyond my capabilities. Of course,
  I do plan on asking Arthur for suggestions regarding memory mapping
  and dynamic loading.  And hopefully I'll learn something and then 
  try it out. In J, BTW, all memory allocation is done in one place 
  so various strategies can be experimented with.

  -Emmett
