macOS using float to calculate sin cos and tan

[gnasher729]

"math" is a collective noun so there is no such thing as "maths".

There's also the subject of geography.

You see, there is this little island in the North Sea, called Great Britain. And the people living on that little island speak proper English aka British English. And when the do maths, they do maths. Not math.

 

[Senor Cuete]

There's also the subject of geography.

You see, there is this little island in the North Sea, called Great Britain. And the people living on that little island speak proper English aka British English. And when the do maths, they do maths. Not math.

According to the dictionary "math" is a mid 19th century abbreviation of the word "mathematics" a plural noun usually treated as singular. So yes, I studied math and also English, but not British English slang.

 

[lloyddean]

If the British speak English it is certainly not proper English.

 

[Qaanol]

Back on topic, I did a quick test of vvsincos and vvsincosf on my mid-2007 MBP, where I found the float version is about 3-4 times faster than the double version when processing the same number of values.

Does anyone with a more recent machine want to test the same thing?

 

[mrichmon]

Back on topic, I did a quick test of vvsincos and vvsincosf on my mid-2007 MBP, where I found the float version is about 3-4 times faster than the double version when processing the same number of values.

Does anyone with a more recent machine want to test the same thing?

If you want to post your code I can run on a 2012 and 2013 rMBP.

 

[Qaanol]

Here’s my test code, written as a command-line utility (be sure to compile for “release”, not “debug”, so it will run at full-speed in Terminal.) Be sure to link the Accelerate framework as well. There is one optional command-line argument to specify the size of the arrays. If omitted, the default is 10,000.

#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#include <vecLib/vecLib.h>

int main (int argc, const char * argv[]) {
	int n = 10000;
	if (argc > 1) {
		n = atoi(argv[1]);
		if (n < 1) {
			printf("First argument must be positive\n");
			return 1;
		}
	}
	time_t t[3];
	float *f1 = malloc(n * sizeof(float));
	float *f2 = malloc(n * sizeof(float));
	double *d1 = malloc(n * sizeof(double));
	double *d2 = malloc(n * sizeof(double));
	srandomdev();
	for (int ii = 0; ii < n; ii = ii + 1) {
		d1[ii] = (double)random();
		f1[ii] = (float)random();
	}
	t[0] = clock();
	vvsincosf(f1, f2, f1, &n);
	t[1] = clock();
	vvsincos(d1, d2, d1, &n);
	t[2] = clock();
	double t1 = (double)(t[1] - t[0])/CLOCKS_PER_SEC;
	double t2 = (double)(t[2] - t[1])/CLOCKS_PER_SEC;
	printf("%f seconds for %i floats\n", t1, n);
	printf("%f seconds for %i doubles\n", t2, n);
	printf("float is %f times the speed of double\n", t2/t1);
	return 0;
}

Here is a typical result on my machine (though to be fair I ran this while streaming video online and the computer was running hot, so who knows what that did to my performance.)

0.577504 seconds for 16777216 floats
2.182337 seconds for 16777216 doubles
float is 3.778912 times the speed of double

 

[gnasher729]

Here’s my test code, written as a command-line utility (be sure to compile for “release”, not “debug”, so it will run at full-speed in Terminal.) Be sure to link the Accelerate framework as well. There is one optional command-line argument to specify the size of the arrays. If omitted, the default is 10,000.

There's a problem with the code that makes the results practically meaningless.

You store the result of random () to be used as the argument of the sine and cosine functions. The values returned by random are in the range from about 0 to 2 billion. That's absolutely non-typical for the arguments of sine and cosine. Worse, when you store a value between 1 and 2 billion into a float, the resolution is 128. That means, the lowest bit has a value of 128, and the difference between two consecutive float numbers is 128. The period of sine and cosine is 2pi. 128 is more than 20 times that period, so for float the actual arguments are totally meaningless. vvsincosf might as well just return 0 and 1 for the sine and cosine for these large values. For double, that's not the case; the arguments even in that huge range still have a resolution of 1/8million radians.

You'd get much more meaningful results if you scaled the values lets say into the interval [-2, +2].

----------

According to the dictionary "math" is a mid 19th century abbreviation of the word "mathematics" a plural noun usually treated as singular. So yes, I studied math and also English, but not British English slang.

"Maths" hasn't been slang for the last 100 years.

 

[Qaanol]

There's a problem with the code that makes the results practically meaningless.

You store the result of random () to be used as the argument of the sine and cosine functions. The values returned by random are in the range from about 0 to 2 billion. That's absolutely non-typical for the arguments of sine and cosine. Worse, when you store a value between 1 and 2 billion into a float, the resolution is 128. That means, the lowest bit has a value of 128, and the difference between two consecutive float numbers is 128. The period of sine and cosine is 2pi. 128 is more than 20 times that period, so for float the actual arguments are totally meaningless. vvsincosf might as well just return 0 and 1 for the sine and cosine for these large values. For double, that's not the case; the arguments even in that huge range still have a resolution of 1/8million radians.

You'd get much more meaningful results if you scaled the values lets say into the interval [-2, +2].

Okay, here is a typical run of my original code without a lot of other programs running:

0.210407 seconds for 16777216 floats
0.773957 seconds for 16777216 doubles
float is 3.678380 times the speed of double

And here is after updating the code:

0.214049 seconds for 16777216 floats
0.782355 seconds for 16777216 doubles
float is 3.655028 times the speed of double

The updated code is identical except the assignments inside the for loop are now:

d1[ii] = 6.2832 * ((double)random() / RAND_MAX);
f1[ii] = (float)(6.2832 * ((double)random() / RAND_MAX));

The times are usually within a couple milliseconds over many runs, so I’d say the result of the test doesn’t change.

"Maths" hasn't been slang for the last 100 years.

This is false. If you go to a major university, even in the USA, and spend some time in the math department graduate lounge, you’ll hear plenty of people refer to their subjects of study as ‘maths’.

 

[Mac_Max]

This is false. If you go to a major university, even in the USA, and spend some time in the math department graduate lounge, you’ll hear plenty of people refer to their subjects of study as ‘maths’.

I think Gnasher's point was that it's not slang because it is a correct word...

Blimy, colour me queer, it's as if the United States are not speaking the same language. (I apologize to all the Brits and Aussies in the room).

For what it's worth:

http://en.wikipedia.org/wiki/Comparison_of_American_and_British_English
http://www.dailywritingtips.com/math-or-maths/

You're all correct.

One thing that always bothers me when I hear British English is the treatment of collective noun - verb agreements. Jeremy Clarkson in particular likes to strongly inflect "have" for dramatic effect.

I.e.

(British) "Germany have won the competition."

v.s.

(US) "Germany has won the competition."

Damn Brits, can't they speak their own language? Back to Math/Maths... It kinda makes sense when you look at the difference in subject-verb agreement between British and US english.

(British) "Maths are difficult."

(US) "Math is difficult."

Both sound reasonable. Swapping our nation's respective agreements...

"Math are difficult."

"Maths is difficult"

Not particularly poetic.

 

[gnasher729]

This is false. If you go to a major university, even in the USA, and spend some time in the math department graduate lounge, you’ll hear plenty of people refer to their subjects of study as ‘maths’.

Missing the point. In the UK, "maths" isn't slang. It is the proper abbreviation for mathematics.

The times are usually within a couple milliseconds over many runs, so I’d say the result of the test doesn’t change.

The point was that you started with totally non-typical value, so you couldn't know whether your results applied to real-world use or not. Seems they do (which is disappointing, since I would have expected shortcuts to calculate sine / cosine faster for typical values), but it still needed verification.

 

[Qaanol]

I think Gnasher's point was that it's not slang because it is a correct word...

Missing the point. In the UK, "maths" isn't slang. It is the proper abbreviation for mathematics.

Yep, I missed that the first time.

The point was that you started with totally non-typical value, so you couldn't know whether your results applied to real-world use or not. Seems they do (which is disappointing, since I would have expected shortcuts to calculate sine / cosine faster for typical values), but it still needed verification.

I'm actually quite glad that the vectorized functions do not make special optimizations for atypical values. That would require testing every single entry to see if the atypical conditions were met, which the vast majority of the time would not be because they are atypical, so the effect would just be to slow down the processing of typical values.

 

[gnasher729]

Yep, I missed that the first time.


I'm actually quite glad that the vectorized functions do not make special optimizations for atypical values. That would require testing every single entry to see if the atypical conditions were met, which the vast majority of the time would not be because they are atypical, so the effect would just be to slow down the processing of typical values.

Excuse me, but that's not how it works. You don't make optimizations for atypical values, you make optimizations for typical values (which possibly isn't happening).

Every implementation of sine / cosine transforms the argument into the range from -pi/4 to +pi/4. In the general case, you multiply the argument by pi/2, round to the nearest integer, multiply by pi/2 _very_ carefully to avoid rounding errors and subtract that from the argument. That's expensive. In the typical case, say -1.25 pi < x < 1.25 pi, all you do is add or subtract pi or pi/2 or leave the argument unchanged. A lot faster. But if you want to do this you _must_ check for the atypical case or get nonsense results.

BTW. Lots of MacOS X / iOS graphics code uses the type CGFloat. On the iPhone 5s, they now use CGFloat = double.