Do you have any pointer on how you've profiled Neanderthal during development?
When I originally set out to compare ND4J and Neanderthal, I've ran into the issue that I bottomed out at: they basically both call MKL (or Openblas) for BLAS operations.
Awesome! I didn't expect you to write that blog post so soon. It will be interesting to find out where the differences (beyond the 'f' ordering thing) are that make Neanderthal so fast, since when I originally started the comparison, both basically boiled down to calling MKL through JNI.
For completeness sake, could you also provide some information about your machine specs and operating system (and if on linux your glibc and kernel version)?
As you can see something happened in the time between the 0.4 release (I took that as the comparison point since that was when I ran my own benchmarks the last time) and the 0.9.1 release that introduced additional overhead.
Originally I planned to create my own write-up on this, but I wanted to first to find out what happened there.
Given that ND4J is mainly used inside of DL4J and the matrix sizes it is used with usually are rather large, the performance overhead difference that I've observed there for tiny multiplications isn't necessarily that bad, as the newer version performs much better on larger matrices.
Your tests, or the output they produce, look awesome. Can you elaborate on your setup? Just today I was looking for an up to date introduction for testing in django, but could only find some older blog posts. So I would be glad if you could detail your setup a bit.
I would also love a more ebook reader friendly format like Mobi or ePub. I still bought it, because I might be able to convert it to something usable for myself, but a version that is actually made for ebook readers (like the sony prs-650 that I have myself :)) would be even better.
I didn't know what Pixel-Perfect is and your README didn't tell me much about what Perfect-Pixels does. I found a short description of it in the project description, but you definitely should add it to your README and this post.
That would take forever, at least on my system, as I don't really have a lot of entropy available. Just for kicks I have started this when I began writing this reply. And now I have the huge amount of 200 Byte in this test file. So thats about 10 bytes per second.
But if you take /dev/urandom you can get quite a bit more. On this system it is about 7Mbyte/s.
My Thinkpad T400s runs at 8W/h when tuned with powertop2 (3g disabled, wlan disabled). But as the battery only has a capacity of 43Wh it only comes up to a bit more then 5 hours.
I could however replace the disk drive for another battery and have about 9 hours of run time with it.
> We're very sorry, but while we would love to let you in and rock out with us, we need to currently restrict turntable access to only the United States due to licensing constraints
It looks like they have killed everything but USA access.
No, tpc-uva is a bit more than what I need right now. I might use it later on when I have decided on any single algorithm that I want to test in a more realistic environment. Because changing the caching algorithm that postgres uses isn't as easy as doing so in a standalone python simulator, I will have to be sure that I want to do that. I have already tried that before and it is a lot harder and takes a lot more time.