helpSimulavr: an AVR simulator - Support: sr #106678, simulavrxx - performance...


sr #106678: simulavrxx - performance investigation

Submitted by:  Joel Sherrill <joelsherrill>
Submitted on:  Thu 12 Mar 2009 07:25:52 PM UTC
Category:  features Priority:  5 - Normal
Severity:  3 - Normal Status:  Postponed
Privacy:  Public Assigned to:  None
Open/Closed:  Open Component Version:  * simulavrxx
Operating System:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


Sat 25 Oct 2014 05:45:58 PM UTC, comment #2: 

This would be a task to do with the current project state. To compare against "competitors" (if somebody will speak so in open source projects) and to find the "place" amongst the others. But on the other hand, whats the benefit? All projects have a different focus and want to be good in different things. It's good to know but then ...

cu, Thomas

Thomas K. <tomk>
Project Administrator
Sun 04 Dec 2011 09:38:56 PM UTC, comment #1: 

Until today's fix about 54% of time was spent in std::muptimap::insert() and erase(), most of it in allocations, called by SystemClock::Step(). Removing the erase() and insert() improves 3.28 MIPS to 9.1 MIPS. On Linux speed rises from 4.80 MIPS to 7.8 MIPS. (Of course we cannot remove those calls, they are needed for certain peripherals and multicore, instead I rewrote it using a minimum heap.)

Commit [2] fixed that, therefore current numbers are 8.2 MIPS (122ns/cycle) on Windows and 9.4 MIPS on Linux. Measurement conditions are below.

I did not test the C simulavr.

For comparison: simulator "avrtest" [1] does 194.7 MIPS when compiled with "-O3 -fomit-frame-pointer", 84.8 MIPS when compiled with -O2. Beware the avrtest was intended to simulate instructions only, not peripherals or interrupts. Still, we have quite a lot to catch up, it is ~10 times faster than us.

All tests were done on my regress\timertest\delay.c, which calls avr-lib'c _delay_loop_2(65535), i.e. sbiw, brne, nop, nop. Both simulavr and avrtest counts the loop as 4 cycles. It runs with interrupts disabled, does not access RAM, does not stress cache by Flash accesses. Number of iterations of calls to _delay_loop_2 is set for test to last several seconds. First launch is used to warm caches and results discarded. Using default optimization levels (-O2 for gcc), no profile guided optimization (would require more effort). Measuring "user" time on Linux, "CPU time" on Windows. Linux builds are on machine named "u-pl12" using gcc-4.5.3 on Intel Core i7 2.67GHz with 8 MiB cache, Windows using MSVS 2010 on Intel Core 2 2.5GHz with maybe 2 MiB cache. Unless otherwise noted there are no other running processes.

I did not use the proposed drystone benchmark because it looks like having complicated set up and it looks like testing quality of C compiler's optimizer, not a simulator. For us any access to RAM (static, Y-relative) is equally fast.


Petr Hluzin <petrh>
Project Member
Thu 12 Mar 2009 07:25:52 PM UTC, original submission:  

I was thinking of how to measure the performance of simulavrxx versus the other AVR simulators and I wondered if the Drystone benchmark might be one comparison.  How long does it take to simulate a run of N iterations?  How long on real hardware?

I am creating this to attach a slightly hacked dry.c file and instructions.  I have no idea how to run this on simulavrxx since I don't have any examples which route avr-libc printf to stdout.  Plus I don't have real hardware. :)

CC=avr-gcc \
CFLAGS="-O2 -mmcu=atmega128" \
sh dry.c

Original version from:

Joel Sherrill <joelsherrill>
Project Administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #17669:  dry.c added by joelsherrill (35KiB - text/plain)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by tomk (Posted a comment)
  • -email is unavailable- added by petrh (Posted a comment)
  • -email is unavailable- added by joerg_wunsch (Updated the item)
  • -email is unavailable- added by joelsherrill (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.





    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-10-25 tomk CategoryNone => features
        StatusNone => Postponed
    2009-03-22 joerg_wunsch Component VersionNone => simulavrxx
    2009-03-12 joelsherrill Attached File- => Added dry.c, #17669

    Back to the top

    Powered by Savane 3.9