Live data from Hacker News

Neanderthal vs. ND4J – Native Performance, Java and CPU

dragan.rocks

1–10 of 27 posts

Re: Neanderthal vs. ND4J – Native Performance, Java and CPU

#3
post #2

Author here. I'm open for discussion. The source is in the text, but conveniently accessible here: https://github.com/uncomplicate/neanderthal/blob/master/exam...

How about running these benchmarks through a time profiler so you can see where the time is actually going?

Re: Neanderthal vs. ND4J – Native Performance, Java and CPU

#4
post #3
post #2

Author here. I'm open for discussion. The source is in the text, but conveniently accessible here: https://github.com/uncomplicate/neanderthal/blob/master/exam...

How about running these benchmarks through a time profiler so you can see where the time is actually going?

Sure! What exactly are you interested in?

Re: Neanderthal vs. ND4J – Native Performance, Java and CPU

#5
post #4
post #3

Earlier quoted context omitted.

How about running these benchmarks through a time profiler so you can see where the time is actually going?

Sure! What exactly are you interested in?

Your hypothesis is that MKL is taking the same amount of time and FFI overhead is the problem. A profiler could confirm your guess about MKL and tell you which part of the overhead is taking the time.

Re: Neanderthal vs. ND4J – Native Performance, Java and CPU

#6
post #5
post #4

Earlier quoted context omitted.

Sure! What exactly are you interested in?

Your hypothesis is that MKL is taking the same amount of time and FFI overhead is the problem. A profiler could confirm your guess about MKL and tell you which part of the overhead is taking the time.

I have to leave some exercises to the reader though ;)

Re: Neanderthal vs. ND4J – Native Performance, Java and CPU

#7
post #2

Author here. I'm open for discussion. The source is in the text, but conveniently accessible here: https://github.com/uncomplicate/neanderthal/blob/master/exam...

Huge thanks for Neanderthal and Bayadera! There is stuff that is basically impossible to run in Stan that becomes feasible on a laptop with a GPU with Bayadera, and the fact that I can do all this in Clojure without having to migrate to Python or worse R has been a great boon.

Re: Neanderthal vs. ND4J – Native Performance, Java and CPU

#8
post #7
post #2

Author here. I'm open for discussion. The source is in the text, but conveniently accessible here: https://github.com/uncomplicate/neanderthal/blob/master/exam...

Huge thanks for Neanderthal and Bayadera! There is stuff that is basically impossible to run in Stan that becomes feasible on a laptop with a GPU with Bayadera, and the fact that I can do all this in Clojure without having to migrate to Python or worse R has been a great boon.

Thanks for the thumbs up!

Re: Neanderthal vs. ND4J – Native Performance, Java and CPU

#9
For anyone interested in looking at or running ND4J benchmarks, these links may be useful.

https://github.com/treo/benchmarking_nd4j/tree/master/src/ma...

deeplearning4j.org/native http://deeplearning4j.org/workspaces

We have our own garbage collection as well as native config and off heap memory management.

We use this

https://github.com/deeplearning4j/deeplearning4j/blob/master...

to specify use of MKL.

Re: Neanderthal vs. ND4J – Native Performance, Java and CPU

#10
DL4J contributor here. I spoke with our team so the differences in performance are likely explained by array ordering. ND4J, for good reason, requires F ordering because of limitations in cuBLAS. While I haven't had the opportunity to closely examine the Neanderthal comparison (I'm also not a clojure user), the likely explanation is that there's an implicit ordering impacting this.

Deeplearning4j is written around F ordering and ND4J supports this. Admittedly, our ordering API is not obvious to the average user.

Here's an example test you can run yourself that demonstrates ordering: https://gist.github.com/raver119/92b615704ca1bf169aa23a6a6e7...

  o.n.i.TensorFlowImportTest - Orders: CCC; Time: 11532 ns;
  o.n.i.TensorFlowImportTest - Orders: CCF; Time: 2101 ns;
  o.n.i.TensorFlowImportTest - Orders: CFC; Time: 10202 ns;
  o.n.i.TensorFlowImportTest - Orders: CFF; Time: 1960 ns;
  o.n.i.TensorFlowImportTest - Orders: FCC; Time: 10744 ns;
  o.n.i.TensorFlowImportTest - Orders: FCF; Time: 1717 ns;
  o.n.i.TensorFlowImportTest - Orders: FFC; Time: 10097 ns;
  o.n.i.TensorFlowImportTest - Orders: FFF; Time: 1716 ns;
We also profiled the above test and confirmed that F -> C ordering adds significant overhead. I can share screenshots if anyone is interested.
Post reply on HN