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.

Sign up for GitHub

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

Jump to bottom

FST dumping is slow #1566

Closed
veripoolbot opened this issue Oct 17, 2019 · 3 comments
Closed

FST dumping is slow #1566

veripoolbot opened this issue Oct 17, 2019 · 3 comments
Labels
area: performance Issue involves performance issues effort: days Expect this issue to require roughly days of invested effort to resolve resolution: fixed Closed; fixed

Comments

@veripoolbot
Copy link
Contributor

Author Name: Wilson Snyder (@wsnyder)
Original Redmine Issue: 1566 from https://www.veripool.org

From https://www.veripool.org/boards/2/topics/2831-Verilator-FST-dumping-100x-slower-than-VCD

  1. Time is being wasted in converting to ascii then back to binary, the GTKWave author is looking at improving this.

  2. The code generally needs to be profiled and analyzed for improvements. Anyone interested in this?
@veripoolbot veripoolbot added area: performance Issue involves performance issues effort: days Expect this issue to require roughly days of invested effort to resolve labels Dec 22, 2019
@gezalore
Copy link
Member

gezalore commented Apr 8, 2020

I could do some profiling of this and attempt improvements, though I wonder if it’s still relevant as there have been recent changes like the API update in 4.026

Do you have a preferred publicly available design to be used for model performance benchmarking? If not I was thinking using verilator_ext_tests/t/t_cores_swerv_cmark.pl

@wsnyder
Copy link
Member

wsnyder commented Apr 8, 2020

t_cores_swerv_cmark.pl is a great choice.

GTKwave made some improvements, I haven't benchmarked since then, but suspect the lowest hanging fruit is still in the gtk wave library & certainly worth looking into. GtkWave (along with us of course) is generally receptive to pull requests.

@wsnyder wsnyder added the resolution: fixed Closed; fixed label May 2, 2020
@wsnyder
Copy link
Member

wsnyder commented May 2, 2020

@gezalore has done a wonderful job improving performance massively. Thanks & think those patches are more than enough to consider this addressed.

@wsnyder wsnyder closed this as completed May 2, 2020
@tomverbeure tomverbeure mentioned this issue Oct 11, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area: performance Issue involves performance issues effort: days Expect this issue to require roughly days of invested effort to resolve resolution: fixed Closed; fixed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@wsnyder @gezalore @veripoolbot