Few weeks ago I remembered a nice little mathematical problem that I solved back in 1982 with my little Sinclair ZX81 computer:
This is the minimal 3x3 magic square (row-, column- and diagonal- sums are identical) consisting of distinct prime numbers only:
113| 59| 5|
17| 89| 71|
This is the (new) C program I wrote to compute the solution in only 6μs on my W541 Thinkpad laptop.
In the last year I played a lot with (Arduino) microcontrollers for (fast) robotics (best was braking robot from 51.7km/h to stand still in 1.8s). Two days ago I used above magic prime square search program for performance comparison of best Arduino microcontroller (Arduino Due, 84MHz, 12$ with free shipping from China, aliexpress.com) with W541 Intel 2.8GHz single core ["only" a factor of 83 ;-)], see this posting for details on problem and comparison:
Having this nice problem and solution at hand I asked myself yesterday what the performance of the program ported to GatewayScript would be compared to optimized C program. I did want to make an apples-to-apples comparison and therefore both need to be executed on the same DataPower platform. And I wanted to use "the real thing", a DataPower IDG appliance and not some virtual DataPower.
Executing code on DataPower IDG can only be done by a DataPower developer, not by a Level2 support engineer nor by IBM Techsales or ISSW people. And it can never be done on an IDG in the field, only on IDG in an IBM lab, and only with a very special firmware.
The first problem to solve was the runtime determination. GatewayScript best precision time determination is parseInt(sm.timeElapsed) with var sm = require ('service-metadata'). But the resolution is only milli second (ms) and not micro second (μs) as needed. Solution to this was to just execute the problem a million times(!) and measure that.
Next I made use of C #define statements in C program that are not available in GatewayScript. Solution was to convert "Prime()" macro into a function and replace the "forall_odd_primes_less_than(p, m, block)" macro with its for loop and Prime() test definitions.
Then I needed to change the array B containing bit coded information about primes in range 0..127 from 64 bit to 32 bit for GatewayScript, because Number.MAX_SAFE_INTEGER is 253-1 which is less than 264.
Finally I changed q.c to q.1M.c and let it the problem solve 1 million times and measure that as well. This is the small diff:
$ diff q.c q.1M.c
> unsigned i,N=1000000;
> for(i=1; i<=N; ++i)
> if (i==N)
This is the execution on IDG -- as I said that can only be done by a DataPower developer:
113| 59| 5|
17| 89| 71|
# head -2 /proc/meminfo
MemTotal: 198192332 kB
MemFree: 195094688 kB
Roughly 3 seconds for 1 million problem solutions, now lets see how GatewayScript performs:
$ coproc2 q.js <(echo '') http://dp3-l3:2227
That really surprised me, only 6.5 seconds for the same 1 million problem solutions! That is only a factor 2.16 slower than optimized C, which I find remarkable for a scripting language.
This is a only a comparison of a very special problem, with a very limited set of GatewayScript language features, so your mileage may vary with GatewayScript performance. But it is a an indicator that you can do even compute intensive GatewayScript actions on DataPower appliances without big implications to overall transaction latency.
This is GatewayScript q.js used (click on it for better view):