Re: [ProgSoc] Java Shtuff

[David Shoon <dshoon@nospam.ftoomsh.progsoc.uts.edu.au>]

On Mon, 29 Apr 2002, Ballarat Central Cornerstone wrote:
> One of the biggest reasons I used a hash table, is because I'd have to use
> my brain to do all the sine cos shtuff, and was wanting to avoid such
> drastic measures. Basically I'm trying to justify my laziness with the
> possible thought that I did it the better (i.e. faster) way anyway.
>
I'm pretty sure java provides a sine/cosine method in some maths
lib/class. The only bit would be to remember to convert degrees to
radians, as almost all sine/cosine functions on a computer require
radians.

radians = degree * pi / 180

> It's only an array of 360 long. Currently it's filled in (the hashtable)
> when the program starts. If I were to manually enter the values into the
> source; i.e. int[] hashtable = {1, .93... etc. could the jvm do
> optimisations... You could declare it const ithink is what I'm getting at.


I don't think there would be much difference in optimisation with a
const keyword.

Matt's also said you could reduce the table to 90. But that's assuming you
want a granularity of 1 degree. A far better idea is to use a smaller
granularity of about 1/100th of a degree and interpolate the rest.

Just out of curiousity I decided to do a benchmark using C on my machine
(PII400mhz/512kb cache) under linux with -O2, with various granularity.
Obviously granularity is irrelevant for the CPU (function-based) sine.
This was for 100 million random sine operations. The smaller the
granularity the larger the table. The table-based sine includes the table
setup time. The test was from 0-90 degrees.

The table size is given by: sizeof(double)  * 90 * 1/gran.

Gran            CPU(sec)        Table(sec)      Table Size(array:bytes)
1               79.51           44.09           90      720
1/10            same            44.71           900     7,200
1/100           same            45.67           9000    72,000
1/1000          same            47.01           90000   720,000
1/10000         same            47.72           900000  7,200,000
1/100000        same            53.63           9000000 72,000,000
1/1000000       same            0.00            Segfaulted

The table with 1/1000th of a degree obviously wouldn't fit inside the
CPU's cache. Table setup is almost irrelevant as I've purposely used a
large amount of sine operations. The segfault is for humour. ;) (~720M
table)

Dave


-
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@nospam.progsoc.uts.edu.au.
If you are having trouble, ask owner-progsoc@nospam.progsoc.uts.edu.au for help.