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

Small patch to speed up $display by reusing an std::string #574

Closed
veripoolbot opened this issue Nov 3, 2012 · 4 comments
Closed

Small patch to speed up $display by reusing an std::string #574

veripoolbot opened this issue Nov 3, 2012 · 4 comments

Comments

@veripoolbot
Copy link

@veripoolbot veripoolbot commented Nov 3, 2012


Author Name: R. Diez
Original Redmine Issue: 574 from https://www.veripool.org
Original Date: 2012-11-02
Original Assignee: R. Diez


Small patch to speed up $display by reusing an std::string, please see the attached patch.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 3, 2012


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-11-03T12:30:17Z


Makes sense. I think it would be almost as efficient and safer to make a "VL_THREAD static string outbuf" inside each function rather than sharing one, see similar examples in verilated.cpp.

I think it looks ok as VL_SFORMATF_NX returns a unique string each time, but please check that sharing the buffer won't cause problems with things like "$sformat("foo%sfoo",$sformat("bar%sbar",var))". (Note in this example you need a var, not a constant string or verilator will constant propagate it into a single constant.)

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 3, 2012


Original Redmine Comment
Author Name: R. Diez
Original Date: 2012-11-03T17:45:56Z


Makes sense. I think it would be almost as efficient and
safer to make a "VL_THREAD static string outbuf" inside
each function rather than sharing one, see similar examples in verilated.cpp.

OK. These are very small, trivial changes, can you do that without a new patch?

I think it looks ok as VL_SFORMATF_NX returns a unique string each time,
but please check that sharing the buffer won't cause problems with things like
"$sformat("foo%sfoo",$sformat("bar%sbar",var))".

The changes are just a speed optimisation, and I haven't got time at the moment to experiment further. If VL_SFORMATF_NX poses questions, can you just leave that routine out? You can add a comment to that routine about such a possible optimisation together with the problematic example above. The next time I come around, I'll look into it.

Thanks,
rdiez

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 4, 2012


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-11-04T00:12:49Z


Turns out in gcc VL_THREAD isn't legal on complex types, so used a macro to make it static only when not threaded, those that thread will have reduced performance for now.

Fixed in git towards 3.842.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 4, 2012


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-11-04T00:25:14Z


In 3.842.

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