[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] [patch #6680] Sine, cosine functions

From: Paulo Marques
Subject: Re: [avr-libc-dev] [patch #6680] Sine, cosine functions
Date: Tue, 08 Jun 2010 15:34:22 +0100
User-agent: Thunderbird (X11/20090817)

Ruud wrote:
> Hi All,
> I listed this under patches, if this is wrong I'm sorry..
> The issues are the sine, cosine functions. When I started to try to speed-up
> the sine function I noticed that version 1.6.3 was quite inaccurate (errors as
> much as 2 times the lsb). So I made a quick draft of an improved? Version..
> See attached file fp_sinus2. This is by no means intended as a final version,
> but is merely meant as an quick draft which needs improving and splitting
> (powsodd should be used by tan, tanh… etc). The results however are quite
> good. See attached sintest.txt (written with notepad windows).  More than
> twice the speed and much better accuracy..

The results look really nice. I haven't looked closely at the source
though, so lets wait for Dmitry's comments on that.

I just wanted to comment on this part:

> How it is tested:
> No simulations, simply had an ATMEGA8 send over all calculations to a PC 
> which verified the results using the FPU

This looks really hard. From the tests it looks like each row takes
about 20 minutes to run, so the entire batch takes around 2 hours?

I would really recommend that you use avrtest for this. I've used it
extensively when doing similar code optimizations and the advantages are:

 - on a Pentium4 3GHz machine I could get the equivalent of a 100MHz
AVR. A modern core2 should go even higher than that, which should
improve the testing time considerably. If the core2 can simulate a
160MHz AVR the testing time will go from 2 hours to 12 minutes...

 - you can do printf's to the console directly, so running your avr code
it's like running a normal console application

 - it already has support for several "counters" (up to 256) that
measure and display clock cycles between start and stop events

 - it takes less time to "flash" the program, so it's easier to automate
the "compile -> run -> get test results" sequence

This kind of code that doesn't interact with avr peripherals is
particularly well suited for this kind of setup.

Anyway, keep up the nice work,

Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

"Feed the hungry, save the whales, free the mallocs!"

reply via email to

[Prev in Thread] Current Thread [Next in Thread]