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
Assignees
Labels
area: performance Issue involves performance issues resolution: fixed Closed; fixed

Comments

@veripoolbot
Copy link
Contributor


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
Copy link
Contributor Author


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
Copy link
Contributor Author


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
Copy link
Contributor Author


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
Copy link
Contributor Author


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)

@veripoolbot veripoolbot added area: performance Issue involves performance issues resolution: fixed Closed; fixed labels Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: performance Issue involves performance issues resolution: fixed Closed; fixed
Projects
None yet
Development

No branches or pull requests

2 participants