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

Optimize poor benchmark result #2501

Closed
brson opened this issue Jun 4, 2012 · 10 comments
Closed

Optimize poor benchmark result #2501

brson opened this issue Jun 4, 2012 · 10 comments
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@brson
Copy link
Contributor

brson commented Jun 4, 2012

http://blog.cdleary.com/2012/06/simple-selfish-and-unscientific-shootout/

We had a particularly poor showing in this comparison.

@brson
Copy link
Contributor Author

brson commented Jun 4, 2012

Thanks @marijnh for pointing it out

@brson
Copy link
Contributor Author

brson commented Jun 4, 2012

Here's what perf says with an optimized runtime and corelib:

 10.64%  test  libcore-d27e4777a53c3e50-0.2.so  [.] uint::to_str::_f7f4236dcee4291a::_02
  9.34%  test  libc-2.15.so                     [.] _int_free
  7.09%  test  libc-2.15.so                     [.] __memset_x86_64
  6.90%  test  librustrt.so                     [.] upcall_s_vec_grow
  6.01%  test  librustrt.so                     [.] upcall_vec_grow
  5.07%  test  librustrt.so                     [.] exchange_malloc
  4.92%  test  librustrt.so                     [.] upcall_exchange_free
  4.72%  test  librustrt.so                     [.] upcall_exchange_malloc_dyn
  4.43%  test  librustrt.so                     [.] check_stack_canary(stk_seg*)
  4.19%  test  libc-2.15.so                     [.] malloc
  4.11%  test  libc-2.15.so                     [.] _int_malloc
  3.07%  test  librustrt.so                     [.] upcall_s_exchange_free
  3.03%  test  librustrt.so                     [.] check_stack_alignment
  3.00%  test  librustrt.so                     [.] upcall_s_exchange_malloc_dyn
  2.18%  test  librustrt.so                     [.] memory_region::malloc(unsigned long, char const*, bool)
  2.15%  test  libc-2.15.so                     [.] realloc
  1.97%  test  [kernel.kallsyms]                [k] 0xffffffff8103d0ca
  1.91%  test  librustrt.so                     [.] get_sp_limit
  1.82%  test  librustrt.so                     [.] memory_region::free(void*)
  1.53%  test  libc-2.15.so                     [.] _int_realloc
  1.33%  test  librustrt.so                     [.] __morestack
  1.31%  test  librustrt.so                     [.] get_sp
  1.19%  test  librustrt.so                     [.] upcall_call_shim_on_c_stack
  0.95%  test  libc-2.15.so                     [.] free
  0.89%  test  librustrt.so                     [.] memory_region::add_alloc()
  0.68%  test  librustrt.so                     [.] upcall_str_new_uniq

@brson
Copy link
Contributor Author

brson commented Jun 4, 2012

It looks like there's a lot to be gained just in optimizing uint::to_str. It is very inefficient.

@kud1ing
Copy link

kud1ing commented Jun 4, 2012

Often in such benchmarks the random number generator is the bottleneck.
Can someone point out where this shows up in the analysis above?

@eholk
Copy link
Contributor

eholk commented Jun 4, 2012

I recently added the xorshift random number generator. It's not on by default, but it should be significantly faster than the default ISAAC generator.

ad292a8

@pcwalton
Copy link
Contributor

pcwalton commented Jun 4, 2012

The biggest win is going to be to write a uint::write or something that directly writes to a file instead of allocating.

@brson
Copy link
Contributor Author

brson commented Jun 4, 2012

6e00852 makes uint::to_str not allocate so much, though it still does one extra allocation when it creates the initial empty vector.

@brson
Copy link
Contributor Author

brson commented Jun 4, 2012

That commit makes the time for time ./test 10000000 go from 32s to 6s.

@brson
Copy link
Contributor Author

brson commented Jun 5, 2012

Graydon made another commit to improve it further. I believe we are competitive with the other languages now.

@brson brson closed this as completed Jun 5, 2012
@kud1ing
Copy link

kud1ing commented Jun 5, 2012

Somewhat related is #2105

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Development

No branches or pull requests

4 participants