NYCJUG/2021-06-08

Beginner's regatta

The "copy" verb, dyadic "#", illustrates how the values of left argument can be taken from increasingly large domains to extend the functionality of the verb in a logical fashion.

Copy is perhaps most commonly used with a Boolean left argument to retain items corresponding to ones and remove those corresponding to zeros.

   1 0 1 # 'ABC'
AC
   1 0 1 0 0 1 # 1 22 333 4444 55555 666666
1 333 666666

If we think of the left argument as specifying the number of copies to make of the compatible list of items on the right, it's easy to see how extending the left argument from Boolean to integer makes sense.

   1 2 3 # 'ABC'
ABBCCC
   (i.5) # i.5
1 2 2 3 3 3 4 4 4 4

Perhaps not as intuitive is the extension of the left argument to complex numbers where the real part specifies the number of copies and the imaginary part specifies the number of fill elements.

   1+j. i.5            NB. Complex left argument specifying increasing more fill elements.
1 1j1 1j2 1j3 1j4
   (1+j. i.5) # i.5    NB. Zero fill elements for zero, one for one, etc.
0 1 0 2 0 0 3 0 0 0 4 0 0 0 0
   (1+j. i.5) # 'ABCDE'
AB C  D   E 

Show-and-tell

Where we see that benchmarks are highly sensitive to many different factors.

Benchmarks

Following are a range of different benchmarks, from those more or less appropriate to J to those of questionable value which attempt to compare performance between languages.

Basic Factors

When looking into some benchmarks proposed on the J forum, I found a set of basic benchmarks I had created some years ago, some results of which are here and code here. These were intended to test a few of the most basic factors affecting overall performance: floating-point and integer arithmetic, and file reads and writes. For example, on a machine running a 2.80 GHz Intel i9-9000 processor, here we see the minimum, maximum, mean and standard deviations of a number of timings.

Starting: 2021 6 7 23 19 2.408
Floating-point arithmetic: min, max, mean, SD:
0.101 0.261955 0.180248 0.0784597
Integer arithmetic: min, max, mean, SD:
0.12477 2.61215 1.35106 1.25349
File writes: min, max, mean, SD:
0.018953 0.0354831 0.0241326 0.00569215
File reads: min, max, mean, SD:
7.06e_5 0.206807 0.0168366 0.0316145
Random File reads: min, max, mean, SD:
0.0186341 0.135364 0.0421362 0.035625
Done: 2021 6 7 23 19 43.083

These benchmarks would be useful for comparing the performance of different versions of J on the same machine or different machines running the same version of J. For instance, here are these timings run on a 1.80 GHz AMD A10-8700P Radeon R6 for the same version of J as the above:

Starting: 2021 6 7 23 29 17.877
Floating-point arithmetic: min, max, mean, SD:
0.694389 1.90298 1.28435 0.544883
Integer arithmetic: min, max, mean, SD:
0.636503 12.7672 6.50783 5.75177
File writes: min, max, mean, SD:
0.0608219 0.16584 0.105032 0.0279952
File reads: min, max, mean, SD:
0.000154 0.323715 0.0413655 0.0740718
Random File reads: min, max, mean, SD:
0.0548537 0.311063 0.153417 0.112474
Done: 2021 6 7 23 32 21.216

This tells us that the first machine is 2.5 to 7 times as fast as the other for these basic operations.

A much older machine, running a 2.40 GHz Intel i5 M520 gives these results:

Starting: 2021 6 7 22 14 41.609
Floating-point arithmetic: min, max, mean, SD:
0.737734 1.9486 1.28483 0.532203
Integer arithmetic: min, max, mean, SD:
0.618851 7.85335 4.17601 3.64397
File writes: min, max, mean, SD:
0.596799 24.4731 2.97664 4.58737
File reads: min, max, mean, SD:
8.08273e_5 1.68123 0.061683 0.12634
Random File reads: min, max, mean, SD:
0.0185441 0.0989287 0.0572687 0.0342837
Done: 2021 6 7 22 19 31.083

This machine is substantially worse on the file-writing benchmark but otherwise is not much worse than the 2nd 1.80 GHz machine (comparing means):

   1.28483 4.17601 2.97664 0.061683 0.0562687 % 1.28435 6.50783 0.105032 0.0413655 0.153417
1.00037 0.64169 28.3403 1.49117 0.36677
 

Both of these latter two machines use SSD drives. One would think this would make quite a difference on the file benchmarks but it does not always do so. Here are the results from running on the first machine but using its SSD drive:

Starting: 2021 6 7 23 50 29.969
Floating-point arithmetic: min, max, mean, SD:
0.0986838 0.251052 0.173908 0.0760136
Integer arithmetic: min, max, mean, SD:
0.123842 2.57652 1.32949 1.23506
File writes: min, max, mean, SD:
0.0211734 0.0348024 0.0259054 0.00524834
File reads: min, max, mean, SD:
7.41e_5 0.111038 0.0224532 0.0402293
Random File reads: min, max, mean, SD:
0.0196967 0.0549903 0.036197 0.015408
Done: 2021 6 7 23 51 12.924

The difference in the file operations:

   0.0241326 0.168366 0.0421362 % 0.0259054 0.0224532 0.036197
0.931566 7.49853 1.16408

So the sequential file read is substantially faster but the others are about the same.

Furthermore, these timings are very sensitive to whatever else is running on the machine, as one would expect.

Attempt at Cross-Language Benchmarks

A correspondent on the J forum proposed some benchmarks in an attempt to do cross-language comparisons but this raises a number of difficulties, not the least of which is that J pays a penalty for code written in an unnecessarily looping fashion. We use

   ts =: 6!:2 , 7!:2@]

to find the amount of time and space a given expression uses.

The benchmarker tried to compensate for this by including both code that mimics the method of scalar languages, for adding up numbers in a loop, and a more J-like version of the same code. So we have the loopy version:

NB. sumloop
NB. loop to sum by incrementing in a loop
NB. done in non-J way
sumloop =: 3 : 0
sum =. 0
for_i. i. y do.
  sum =. sum + 1
end.
sum
)

And the more J-like version:

NB. sumj
NB. sum consecutive integers as in J
sumj =: 13 : '+/ y$1'

As one might expect, the loopy version is slower:

   (10) 6!:2 'sumloop 1e6'
0.19529
   (10) 6!:2 'sumj 1e6'
0.00053342
   0.19529%0.00053342
366.109

However, I would argue that an even more J-like version would be this one:

   sumj2=: <:@:>:^:#   NB. Loop using the power conjunction
   (10) 6!:2 'sumj2 1e6'
1.82e_6
   (10) 6!:2 'sumj 1e7'
0.00322712
   (10) 6!:2 'sumj2 1e7'
1.66e_6
   (10) 6!:2 'sumj 1e8'
0.0372194
   (10) 6!:2 'sumj2 1e8'
1.73e_6

This one seems to take the same amount of time regardless of its argument and is enormously faster:

   0.0372194%1.73e_6
21514.1

Adjusting a Benchmark Using Inside Knowledge

Henry Rich responded to this thread by noting that "[b]enchmarks such as these are hard to make meaningful and easy to misuse, perhaps maliciously."

He gives an example of what he calls a "counterbenchmarks: problems to show off the really beautiful algorithms in JE" (J engine):

1. grade 1e4 integers.  I pick 1e4 because it fits in cache.  If the
arguments are too long the CPU is waiting for memory
    CLOCKSPEED =: 2.5e9   NB. My CPU's clock frequency
    r =: 1e4 ?@$ 2e4
    (#r) %~ CLOCKSPEED * 100000 (6!:2) '/: r'
12.2257   NB. 12 cycles per atom!
    r =: 1e4 ?@$ 1e9
    (#r) %~ CLOCKSPEED * 100000 (6!:2) '/: r'
54.1968

The caching effect is noticeable. Here we see that increasing the size of the argument by a factor of 10 takes 14 times as long:

   r =: 1e4 ?@$ 2e4      NB. 1e4 fits in cache
   100000 (6!:2) '/: r'
4.74625e_5
   r =: 1e5 ?@$ 2e4      NB. 1e5 exceeds cache
   100000 (6!:2) '/: r'
0.000691088
   0.000691088 % 4.74625e_5
14.5607

A Classic Array-language Benchmark Through the Years

Finally, no exposition of J benchmarks would be complete without referring to one that has been used in the APL world for quite few years: matrix inversion of a 50 by 50 matrix of integers, i.e. 6!:2 '%.?50 50$1000' in J. Looking here, we see that the time for this has come down from over 2800 seconds in 1990 to 5.6e_5 seconds recently, speedup of about 50 million times.

Learning and Teaching J

Dan is teaching himself Dyalog and would like any help anyone can offer. He has been putting together a Rosetta Stone page between APL and J here.

This reminded me of a talk a while back about someone going in the opposite direction.

An APLer Learning J

Back in 2009, Paul L. Jackson, a long-time APLer, gave a talk on his rewarding experience learning J as someone coming from an APL background.

Paul cannot pin down exactly when he started learning J because his Microsoft Exchange emails are unavailable due to his unwillingness to use MS software in the past 10 years.

He showed us a cheat sheet to map APL to J equivalents. He uses J as a "broken key" APL, i.e. with work-arounds for parts he does not yet understand. Here is an example similar to Dan's Rosetta page where he aligns equivalent APL and J primitives.

He has been working on writing a version of APL in .NET which reflects an effort that STSC had begun.

While working on his own Javascript implementation of APL, he met someone working on an APL in JavaScript. This is Joe Bogner, who was on the call. Apparently he had trouble implementing adverbs and he had a philosophical objection to quad-CT so Paul added it to the implementation. Paul was favorably impressed by the performance of APL written in JavaScript.

He notes J's prejudice toward the first dimension. There had been talk of defaulting to first dimension at least back as far as Roland Pesch working on SAX(?), so Ken had been thinking of this for some time before Arthur Whitney got approval of this for A+. Arthur came back from a weekend with Ken and declared "Dad said it was OK". This seems obvious in retrospect when looking at concatenation since it's much easier to add a new row than a new column.

There was also dispute about how encode and decode worked - Larry Breed wanted compatibility between decode and encode with inner product.

Brackets seem truly foreign even in old APL. He had a point about parenthesis usage:

   this=: |.>:i.3
   this; 2 3; 'fun'         NB. This works
NB. but
   this; i. 2 3; 'fun'      NB. This fails
   this; (i. 2 3) ; 'fun'   NB. We need to this because of right-to-left execution.

This sort of things trips up novices even now.

He also had a comment about internal event-handling, how it changed to more of an object model to base the locus of execution on which object has focus.

Looking at J's z vs. j Namespaces and Paul's Utilities

All names that begin with uppercase are for public consumption; those beginning with lowercase are internal, as seen here.

If you work with a language that keeps its code in text files rather than in workspaces, you don't want something like ")SAVE" with no argument.

His set of names is now publicly available; they have what he sees as handy default behavior, e.g. Load re-loads the last thing loaded as seen in the examples here.

Continuing...

Continuing...

Adverbs and Conjunctions

He had inadvertently left an argument ("y" or "x" and "y") out of a definition and found that this returned something other than a function - adverb or conjunction returns a verb. Leaving off "x" or "y" does this. Leaving off the "u" or "v" returns a value error on "y".

"Del" is his most-used one-liner ever.
"Dr" is a verb; "Rn" is a conjunction: <directory> Rn View
So, "'lessons' Rn View" looks at what has been done already and picks up where it left off. He uses the abbreviation "LRC" for "Load, Run, Copy".

Here is a list of some of his utilities:

His utilities often work with the clipboard, taking implicit arguments from there.

His "Use" verb does different things based on the file extension but load, run, and copy know on which extension it should work.

All his publicly-available work is here or thereabouts.

Joe Bogner asked about Paul's use of Android: has he used J on laptop or such? He seems geared toward a simple interface based on his extensive use of beta releases. He feels more comfortable looking down like reading a book rather than looking up to a laptop screen.

"plj" is publicly available namespace; "pj" is the internal namespace. The convention of starting a public namespace with "p" is documented somewhere?

Podcasts

Adam Gordon Bell interviewed software evangelist Gabriel Gonzalez on the Corecursive podcast. Among other things, they talked about how a language becomes popular.

The second Array Cast podcast is now available.