Here is some data on operator speed. All of these were sampled at least 5 times (many were sampled 6 times) and below is the mean as well as the relative standard deviation of the samples.

These were all performed in decimal, single precision mode with a stack depth of 4.

To measure these I used a program that has a 30 second (using tick) loop with the operator being measured in the middle. I then run the same program with two of the operators in the loop, and then three of the operators, etc. The delta between adjacent runs measures the impact of adding a single operator to the loop.

The raw data can be found in this spreadsheet:

Libreoffice (OpenOffice?) Spreadsheet

It seems that the actual value of the number can have a significant value on the speed of the operations. For example for the 4 basic operations, I tested once using just whole numbers (but not in integer mode) and once using random values generated by the random number function.

For the the exponential functions, I use the value on the stack from the previous operation. This means that the range of values is huge and changes drastically. You can see that the impact that has on the relative standard deviation of the samples.

Operation	Ops per second		Milliseconds per op		Relative Standard Dev

+ (whole #)	4,218			0.24				3.82%

+ (rand dec #)	2,729			0.37				3.60%

x (whole #)	4,115			0.24				1.33%

x (rand dec #)	2,134			0.47				4.36%

- (whole #)	4,421			0.23				0.93%

- (rand dec #)	3,402			0.29				3.14%

/ (whole #)	3,688			0.27				2.41%

/ (rand dec #)	979			1.02				1.65%

Sqrt		221			4.52				2.50%

R[v]		7,431			0.13				2.63%

R[^]		7,340			0.14				2.28%

y^x		35			28.75				1.43%

sin		47			21.06				3.57%

cos		46			21.84				5.40%

ln		21			47.41				7.60%

e^x		57			17.60				25.27%

1/X		1,068			0.94				1.97%

Edited: 15 Sept 2013, 2:14 p.m.

Nice! Can you do a wiki article about this?

Nice results. The CPU in the 30b is really good at shuffling data around.

The number of digits in a number will impact the performance for the basic arithmetical operations. The decNumber library knows how many digits are in a number and doesn't process the trailing zeros. The library also has some shortcuts -- e.g. multiplication by zero.

- Pauli

I want to run analogous tests on the 15CLE and then I'll post the code and results all together.

The trailing zero optimization seems to make quite a difference.

One thing that I found striking is that if R[v] and R[^] are indicative, then a significant portion of the time spent in the basic math operations is the stack drop and the arithmetic itself is impressively fast.

I suspect the time is more in the interpretive overhead for the opcode dispatch. There is quite a lot that goes on there. The stack roll operations are a couple of memory copies which are quick.

I'm not sure how to best test this. NOPs might work but they don't go through the entire dispatch sequence. Integer mode bitwise operations might be better.

- Pauli