4 ms·

Go vs Java: Decoding Billions of Integers Per Second

21 points by zhenjl 13y ago

cordite 13y ago
The images do not work for me.
- zhenjl 13y ago
  Interesting. Those are served from Google. Not sure what's going on there. Anyone else have this problem?
  - laurenstill 13y ago
    Works fine for me, chrome/ubuntu.
  - msie 13y ago
    Images aren't working for me either.
  - bsg75 13y ago
    The images and data don't show for me. Chrome asked me to sign in with my Gmail account, which I declined to to. Could that have something to do with the missing images?
    - zhenjl 13y ago
      bsg75, thanks for this. I updated to serve images from the site instead of from Google. Hopefully this helps. Please let me know if you still run into problems. I haven't updated the data section yet.
      - bsg75 13y ago
        404: http://zhen.org/blog/go-vs-java-decoding-billions-of-integers-per-second/images/2013-11-14-go-vs-java-decoding-billions-of-integers-per-second/java_vs_go_faster.png http://zhen.org/blog/go-vs-java-decoding-billions-of-integer...
        zhenjl 13y ago
        Ok, I think I definitely fixed it now. Thanks for the heads up.
  - geetarista 13y ago
    I get a 404 when trying to view them.
deleted 13y ago
[deleted]
zhenjl 13y ago
I just finished updating the code with an assembly version of a hot function (finding the leading "1" bit position) and updated the blog to reflect the improvements. In general I saw a 3-40% performance increase using the assembly version, which I borrowed from math/big/arith_*.s. The reason for the wide range is because it depended on the size of the delta integers being processed.
zhenjl 13y ago
2013-11-17 Update #2: Tried another new trick. This time I updated the leading bit position function, when using the gccgo compiler, to use libgcc’s __clzdi2 routine. This had the same effect as the update #1 except it’s for when gccgo is used. Performance increase ranged from 0% to 20% for encoding only. Thanks dgryski on reddit and minux on the golang-nuts mailing list.
LocalMan 13y ago
Did you use any parallelism/concurrency? There ought to be a way to speed up the Go version with parallelism. This is fair as that is one of Go's strengths.
- zhenjl 13y ago
  I did not. It might be difficult tho for all the delta encoding methods since they all depend on computing delta from the previous integer. For the non-delta methods it is conceivable that ||ism may help, but not sure by how much.

21 points by zhenjl 13y ago

cordite 13y ago

The images do not work for me.

zhenjl 13y ago
Interesting. Those are served from Google. Not sure what's going on there. Anyone else have this problem?
- laurenstill 13y ago
  Works fine for me, chrome/ubuntu.
- msie 13y ago
  Images aren't working for me either.
- bsg75 13y ago
  The images and data don't show for me. Chrome asked me to sign in with my Gmail account, which I declined to to. Could that have something to do with the missing images?
  - zhenjl 13y ago
    bsg75, thanks for this. I updated to serve images from the site instead of from Google. Hopefully this helps. Please let me know if you still run into problems. I haven't updated the data section yet.
    - bsg75 13y ago
      404: http://zhen.org/blog/go-vs-java-decoding-billions-of-integers-per-second/images/2013-11-14-go-vs-java-decoding-billions-of-integers-per-second/java_vs_go_faster.png http://zhen.org/blog/go-vs-java-decoding-billions-of-integer...
      - zhenjl 13y ago
        Ok, I think I definitely fixed it now. Thanks for the heads up.
- geetarista 13y ago
  I get a 404 when trying to view them.

deleted 13y ago

[deleted]

zhenjl 13y ago

I just finished updating the code with an assembly version of a hot function (finding the leading "1" bit position) and updated the blog to reflect the improvements. In general I saw a 3-40% performance increase using the assembly version, which I borrowed from math/big/arith_*.s. The reason for the wide range is because it depended on the size of the delta integers being processed.

zhenjl 13y ago

2013-11-17 Update #2: Tried another new trick. This time I updated the leading bit position function, when using the gccgo compiler, to use libgcc’s __clzdi2 routine. This had the same effect as the update #1 except it’s for when gccgo is used. Performance increase ranged from 0% to 20% for encoding only. Thanks dgryski on reddit and minux on the golang-nuts mailing list.

LocalMan 13y ago

Did you use any parallelism/concurrency? There ought to be a way to speed up the Go version with parallelism. This is fair as that is one of Go's strengths.

zhenjl 13y ago
I did not. It might be difficult tho for all the delta encoding methods since they all depend on computing delta from the previous integer. For the non-delta methods it is conceivable that ||ism may help, but not sure by how much.