Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Benchmark --protect-lib runtime #1519

Closed
veripoolbot opened this issue Sep 24, 2019 · 4 comments
Closed

Benchmark --protect-lib runtime #1519

veripoolbot opened this issue Sep 24, 2019 · 4 comments

Comments

@veripoolbot
Copy link

@veripoolbot veripoolbot commented Sep 24, 2019


Author Name: Todd Strader (@toddstrader)
Original Redmine Issue: 1519 from https://www.veripool.org

Original Assignee: Todd Strader (@toddstrader)


There's obviously overhead in shuttling data back and forth with --dpi-protect. We should use some large-ish design (maybe a processor) and --dpi-protect a part of it and compare runtimes. This will help us judge future performance enhancements to see if we're going in the right direction. Also, we can plug this whole thing into verilator_ext_tests.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Oct 22, 2019


Original Redmine Comment
Author Name: Todd Strader (@toddstrader)
Original Date: 2019-10-22T22:01:48Z


See:
https://github.com/toddstrader/verilator-dev/tree/prot-lib-benchmark

This adds t_noprot_lib which is the same as t_prot_lib but without --protect-lib. These can be run against each other with or without tracing. For reference, on my system I see:

t_prot_lib.pl --notrace --benchmark 10000000
12.03user 0.00system 0:12.04elapsed 99%CPU (0avgtext+0avgdata 1056maxresident)k
t_noprot_lib.pl --notrace --benchmark 10000000
0.25user 0.00system 0:00.25elapsed 99%CPU (0avgtext+0avgdata 3184maxresident)k
t_prot_lib.pl --benchmark 100000
1.66user 0.50system 0:02.20elapsed 98%CPU (0avgtext+0avgdata 1212maxresident)k
t_noprot_lib.pl --benchmark 100000
0.39user 0.11system 0:00.50elapsed 99%CPU (0avgtext+0avgdata 3296maxresident)k

Note:

  • The tests run with --trace by default so that they can grep the VCDs
  • Tracing tests are run with smaller cycle counts because I can't wait that long
  • --protect-lib performance is currently not great, but I don't think that's really a surprise
@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Oct 22, 2019


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-10-22T22:26:16Z


Not sure if you are proposing to merge this...

  1. Some tabs got into t_prot*, please squash them.

  2. You shouldn override the sim_time check in driver as this may lead to infinite runtimes, instead put in the .pl file a big number:

    $Self->{sim_time} = 100000;

With those feel free to merge (if you want to).

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Oct 23, 2019


Original Redmine Comment
Author Name: Todd Strader (@toddstrader)
Original Date: 2019-10-23T17:06:36Z


Yeah, sorry. The intent is to push this. I'm sure we'll want to evolve the benchmarking over time, but focusing on the I/O copy overhead (which is what this demonstrates) seems like a good place to start.

Re: tabs, they snuck in because I was using this for Verilog formatting:

emacs --batch <filenames.v> -f verilog-batch-indent

Squashed and pushed.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 10, 2019


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-11-10T19:30:05Z


In 4.022.

(& thanks for all your work in this release)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.