On 11/29/13, 9:16 PM, Cedric Greevey wrote:
On Fri, Nov 29, 2013 at 11:03 PM, Ben Mabey <b...@benmabey.com
<mailto:b...@benmabey.com>> wrote:
On 11/29/13, 8:33 PM, Cedric Greevey wrote:
Have you checked for other sources of performance hits? Boxing,
var lookups, and especially reflection.
As I said, I haven't done any optimization yet. :) I did check
for reflection though and didn't see any.
I'd expect a reasonably optimized Clojure version to outperform a
Python version by a very large factor -- 10x just for being
JITted JVM bytecode instead of interpreted Python, times another
however-many-cores-you-have for core.async keeping all your
processors warm vs. Python and its GIL limiting the Python
version to single-threaded performance.
This task does not benefit from the multiplexing that core.async
provides, at least not in the case of a single simulation which
has no clear logical partition that can be run in parallel. The
primary benefit that core.async is providing in this case is to
escape from call-back hell.
Hmm. Then you're still looking for a 25-fold slowdown somewhere. It's
hard to get Clojure to run that slow *without* reflection, unless
you're hitting one of those cases where parallelizing actually makes
things worse. Hmm; core.async will be trying to multithread your code,
even while the nature of the task is limiting it to effectively serial
performance anyway due to blocking. Perhaps you're getting some of the
slowdown from context switches that aren't buying you anything for
what they cost? The GIL-afflicted Python code wouldn't be impacted by
the cost of context switches, by contrast.
I had expected the context-switching to take a hit but I never tried to
see how much of a hit it is. I just did and I got a 1.62x speed
improvement[1] which means the clojure version is only 1.2x slower than
the simpy version. :)
Right now the thread pool in core.async is hardcoded in. So for this
experiment I hacked in a fixed thread pool of size one. I asked about
having the thread pool for core.async be swappable/parametrized at the
conj during the unsession and the idea was not received well. For most
use cases I think the current thread pool is fine but for this
particular one it appears it is not...
-Ben
1. Full benchmark... compare to times here:
https://gist.github.com/bmabey/7714431
WARNING: Final GC required 5.486725933787122 % of runtime
WARNING: Final GC required 12.905903007134539 % of runtime
Evaluation count : 6 in 6 samples of 1 calls.
Execution time mean : 392.457499 ms
Execution time std-deviation : 8.225849 ms
Execution time lower quantile : 384.192999 ms ( 2.5%)
Execution time upper quantile : 401.027249 ms (97.5%)
Overhead used : 1.847987 ns
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
