Newsgroups: comp.lang.apl
Path: watmath!watserv2.uwaterloo.ca!torn!howland.reston.ans.net!noc.near.net!uunet!gumby!calvin!ursa!abalje47
From: abalje47@ursa.calvin.edu (Alan Baljeu)
Subject: Re: efficient J programs (shellsort)
Message-ID: <abalje47.735948061@ursa>
Sender: news@calvin.edu (The Annoying News Pseudo-User)
Nntp-Posting-Host: ursa
Organization: Calvin College
References: <abalje47.735520194@ursa> <1993Apr23.203153.822@csus.edu> <abalje47.735855110@ursa> <1993Apr27.061401.27676@csus.edu>
Date: Tue, 27 Apr 1993 22:01:01 GMT
Lines: 54

>>Why is boxing so expensive?
>>I would have guessed boxing would be implemented by creating an array of
>>pointers to the original object. Indirection is not a very costly operation,
>>really.  It sounds like entire arrays are being copied over.
>>
[...]
> You may find it of interest to look at the memory 
> usage in the following session :

>   7!:2 'a =. i. 300 300'
>720420
>   7!:2 '<a'
>360184
>   7!:2 'b=. <a'
>360272
Add a few tests:
   7!:2 'a'
120
   7!:2 'b =. a'
220
   7!:2 '1 + a'
1080268

>  I don't know what one can conclude from this. At least the entire
>  array is not recopied but this doesn't look like simple indirection
>  either.
>   
From what I see, I can say this.  An integer is 4 bytes long.  300*300
integers yields 360000.  So yes, boxing does recopy the entire array.
Hence it is obvious the first test creates a 2d array, and copies it.
(why copy??).  The boxing operation apparently creates a new copy as well.
In fact, it seems that doing any operation on the array generates extra
space.  Adding a variable seems ok.  
Adding 1 to the array is atrocious!  

It seems to me the implementors would do well to work this overhead out 
of the system.

>  If efficiency is _really_ important , you can write a 10!:k verb.
>  As you can see in my recent post, I implemented a verb
>  using tacit defintion in J and then implemented its' 10!:0 
>  counterpart, and the 10!:k verb was 25 times faster.
Only 25?  I remember reading a conference article citing 800 as the factor
between APL and C.  Efficiency is not the most important issue to me now.
It's just that I see _lots_ of room for improvement.  I hope the implementors
will work on some of this.

I trust it isn't too hard.

Alan Baljeu

--
			 Alan Baljeu
abalje47@ursa.calvin.edu
