12 replies to this topic

[Xerxes]

I don't know, if some of you have seen this Calculator Benchmark.
If you think that the CP-300 has to be on the list too, more results are welcome.
If the C code is not portable, a structured Pascal version is available at the link too.

int main()
{
  int x,y,r,s,t,n,a[9];
  for(n=100;n>0;--n){ /* repetitions for timing */
	r=8;
	s=0;
	x=0;
	
	do{
	  a[++x]=r;
	  do{
		++s;
		y=x;
		while(y>1)
		  if ((t=a[x]-a[--y])==0 || x-y==abs(t)){
			y=0;
			while(--a[x]==0)
			  --x;}
	  } while(y!=1);
	} while(x!=r);

  }
  printf("%d",s);
  beep(1);
  return 1;
}

[Orwell]

You can use the following translation in Lua with CPLua for benchmarking.

function abs(a) if a>=0 then return a else return -a end end
  
for n = 100,1,-1 do  -- timing
  r=8
  s=0
  x=0
  a = {}
  repeat
	x = x+1
	a[x] = r
	repeat
	  s = s+1
	  y = x
	  while y>1 do
		y = y-1
		t = a[x] - a[y]
		if (t==0) or (x-y==abs(t)) then
		  y = 0
		  a[x] = a[x]-1
		  while a[x]==0 do
			x = x-1
			a[x] = a[x]-1
		  end
		end
	  end
	until y==1
  until x==r
end
print(s)

Note that you should do the same benchmark with CPBasic and in C++ (by building a small CP Add-in)

[Xerxes]

Thank you for translation. Looks more like Pascal than C. The algorithm of the structured version is the same as the non-structured. If both are executable, I use the faster one for timing. This is a compromise of another forum, I have the most results from, between speed and usability also on keystroke programmable calculators.

Note that you should do the same benchmark with CPBasic and in C++ (by building a small CP Add-in)

A good idea, but I don't have a CP-300. I have bought a FX-9860GSD because I don't need CAS.

I think the result of the CP-300 at C is very interesting. Due to the result of the FX-9860G of 2.48 msec I guess the SH3 runs at 20 and not 40 MHz, considerating the result of the HP-50G of 0.779 msec at 75 MHz.

[kucalc]

I think the result of the CP-300 at C is very interesting. Due to the result of the FX-9860G of 2.48 msec I guess the SH3 runs at 20 and not 40 MHz, considerating the result of the HP-50G of 0.779 msec at 75 MHz.

The fx-9860 SDK automatically optimizes programs for SIZE not speed. Look in the MAKEFILE of your projects folder for proof. So you get all the size optimization tricks added into your program which is suppose to make the program smaller, but in return your add-ins become slower. To get an idea of how fast the program would actually be when optimized for SPEED (but the add-ins size becomes larger), divide 2.48 by 2.5: ~0.99 milliseconds. Pretty good at only 40MHz. Imagine when it's clocked 133MHz....

[Xerxes]

Is it possible to change the compiler options? I cannot find it in the SDK.

[PAP]

Looks more like Pascal than C.

In general Lua looks much more close to C than Pascal to me. Unfortunately.

[Xerxes]

I agree. A on-calc Pascal compiler with inline assembler would be the optimum for the CP-300 or FX-9860G.

[kucalc]

Is it possible to change the compiler options? I cannot find it in the SDK.

Sorry about my delay replying. I'm usually very quick in replying here on this forum.

You can change the compiler settings by editing the settings in the MAKEFILE. The problem is compiling. Don't compile using the fx-9860 SDK IDE, as it rewrites the MAKEFILE everytime you compile. You have to run the MAKEFILE script through the Command Prompt (MS-DOS Window) by hand.

[Xerxes]

Hi kucalc,

I have made following steps to compile with optimization for speed:

- changing -size to -speed in the Addin.mak file
- running FXSH_Build.bat

The file qbench.g1a has been created successfully but the execution speed does't changed.

[Xerxes]

I have tested the ClassPad now:

With 128 sec (unstructured) and 142 sec (structured) the Casio Basic is very slow in comparison to the FX-9860G with 17.3 sec.

The speed of CPLua is really impressive compared to Casio Basic. It needs 1.10 sec for the benchmark only that is 116 times faster!

It is remarkable that declaring all variables as local instead of global makes the execution speed ~2.3 times faster. This is the biggest difference I have tested so far.

@Orwell:
If you don't mind, I have modified your source a bit for faster execution.

[PAP]

The speed of CPLua is really impressive compared to Casio Basic. It needs 1.10 sec for the benchmark only that is 116 times faster!

Thank you for having the patience to write such a code in CPBasic, and performing this test. I don't think that anyone in this forum will be surprised by the result you have obtained, but it's nice to know anyway.

It is remarkable that declaring all variables as local instead of global makes the execution speed ~2.3 times faster. This is the biggest difference I have tested so far.

I always avoid global variables, because this is a good programming style. Each chunk of code must "know" what it needs to know, and nothing else; therefore, using local variables is a must, otherwise you break the "data hiding", which is very dangerous. However, each time a function is called, the interpreter must allocate memory for local variables, and deallocate that memory when exiting the function. So, using local variables is expected to increase execution time, especially if some functions are called several times (which is the rule, not the exception). It is really strange that you have experienced the opposite. Orwell, can you explain this?

[Xerxes]

After reading around here I was not suprised that Lua is much faster, but I was surprised of the very slow CP Basic. Before testing CP Basic I lead from that the speed is similar to the FX-9860G due to the SH3 used in both calculators.

IMO CPLua is the most useful CP-300+ Add-In. Well done Orwell.


Here is the code for benchmarking:

local a,r,s,t,x,y,n
for n=1,100 do  -- repetitions for timing
  r=8
  s=0
  x=0
  a={}
  repeat
	x=x+1
	a[x]=r
	repeat
	  s=s+1
	  y=x
	  while y>1 do
		y=y-1
		t=a[x]-a[y]
		if t<0 then
		  t=-t
		end
		if (t==0) or (x-y==t) then
		  y=0
		  a[x]=a[x]-1
		  while a[x]==0 do
			x=x-1
			a[x]=a[x]-1
		  end
		end
	  end
	until y==1
  until x==r
end
print(s)

Note that the allocation of variables is only at the beginning of the code, so it means that access to local variables is unusual faster than global ones.

[Orwell]

If you don't mind, I have modified your source a bit for faster execution.

Of course I don't mind

I always avoid global variables, because this is a good programming style. Each chunk of code must "know" what it needs to know, and nothing else; therefore, using local variables is a must, otherwise you break the "data hiding", which is very dangerous.

... but strict data hiding has a price, because it brings an important restriction for flexibility and reusability (Of course I'm against the use of "simple" global variables; I just wanted to add this little precision )

However, each time a function is called, the interpreter must allocate memory for local variables, and deallocate that memory when exiting the function. So, using local variables is expected to increase execution time, especially if some functions are called several times (which is the rule, not the exception).

Well, not exactly... This is how it works in C language, but Lua (as most modern languages) works a bit differently. In fact it does not deallocate the local variables when exiting the function, but when the interpreter considers that it is the right time to do it; there is no individual deletion of each local variable at the end of the function. So memory deallocation isn't a problem here, however as you said memory allocation can slow down the execution speed.

It is really strange that you have experienced the opposite. Orwell, can you explain this?

It is difficult for me to give you a complete explanation, because I don't know exactly how the Lua interpreter works. And I must say it's not the first time I see such a surprising fact
Anyway, I think that I can give you some details about it.
The first thing is that he's not using local variables inside a function, but inside a chunk, so there is no repeted allocation process as PAP mentionned.
And the second thing comes from the way the interpreter looks for variables or functions. When the interpreter detects the use of a variable (or functions etc), it must find how it has been declared. It starts by browsing among the local variables, then it checks the global variables if it didn't find the reference yet. This is the correct behaviour, because local variables must "overload" the global variables with the same name without erasing it. So basically the access to global variables is a litte bit slower than to local variables.
(It may be a little more complicated, because the interpreter must deal with the different code environments etc, but the main principle is there).

I hope it answered to your question