On Jan 13, 10:07 am, cliffc wrote:
-snip-
> 5- The debianshootoutresults generally badly mis-represent Java.
> Most of them have runtimes that are too small (<10sec) to show off the
> JIT, and generally don't use any of the features which commonly appear
> in large Java programs (heavy use of v
On 13.01.2009, at 19:07, cliffc wrote:
> 1- If you think that HotSpot/Java is slower than C++ by any
> interesting amount, I'd love to see the test case. Being the
I have to admit that I haven't done many tests, but for those I did I
found little to no difference, provided the tests have suff
On Jan 15, 12:09 am, bOR_ wrote:
> I remember from 5 years ago that a collegue of mine improved a
> diffusion algorithm for a successor of me by some heavy algorithms. My
> own algorithm was a simple loop-over-the- array once, dump-a-fraction-
> of-each-cell-into-spatially-neighbouring-cells-in-t
I remember from 5 years ago that a collegue of mine improved a
diffusion algorithm for a successor of me by some heavy algorithms. My
own algorithm was a simple loop-over-the- array once, dump-a-fraction-
of-each-cell-into-spatially-neighbouring-cells-in-the-new-array, and
sum what is in every cel
On Jan 14, 6:37 pm, Asbjørn Bjørnstad wrote:
> Look closer, I'm using a 1-D array and indexing by hand :-)
oops, sorry about that -- i see you are doing the right thing here ;-)
> > 3. I noticed you are doing 20 iterations of Gauss-Seidel. There are
> > some smart ways to speed up multiple st
On Jan 15, 4:33 am, Rich Hickey wrote:
> Try this (and make sure you are using -server):
>
> (defn diffuse [grid diff-ratio dt]
> (let [a (float (* dt diff-ratio grid-size grid-size))
> a4-1 (float (+ 1 (* 4 a)))
> grid #^floats (deref grid)
> diffused-grid #^floats (ma
On Jan 13, 8:04 am, Mark P wrote:
> > A macro cannot depend on runtime information. A macro is a function
> > that is called at compile time, its argument is an expression (as
> > written by the programmer, or as returned by another macro), and its
> > result is a modified expression. There
On Jan 15, 8:42 am, "Mark H." wrote:
> On Jan 14, 12:29 pm, chris wrote:
>
> > For a completely different way of doing this, you could certainly use
> > GPGPU programming to speed this up.
> > ...
> > You want this for a game engine anyway; do it in opengl or directx
> > using shaders.
>
> I re
On Jan 15, 3:38 am, "Mark H." wrote:
> On Jan 14, 8:27 am, Asbjørn Bjørnstad wrote:
>
> > Anyway, here is a core part of the algorithm. It's a diffusion
> > step, this gets called 3 times and in total this takes up more than
> > one second of cpu time on my machine which makes framerates very
On Jan 14, 12:29 pm, chris wrote:
> For a completely different way of doing this, you could certainly use
> GPGPU programming to speed this up.
> ...
> You want this for a game engine anyway; do it in opengl or directx
> using shaders.
I recommend OpenCL or CUDA instead for less pain ;-) (Well,
On Jan 14, 11:27 am, Asbjørn Bjørnstad wrote:
> On Jan 14, 12:20 pm, "Mark H." wrote:
>
>
>
> > I humbly propose that folks shouldn't complain about Clojure being
> > slow for their apps until they have at least one of the following:
>
> > 1. A targeted benchmark for an important bottleneck i
For a completely different way of doing this, you could certainly use
GPGPU programming to speed this up.
This section:
(aset diffused-grid c
(float (/ (+ (aget grid c)
(* a
(+ (+ (aget diffused-gr
On Wed, Jan 14, 2009 at 11:27 AM, Asbjørn Bjørnstad wrote:
>
> Anyway, here is a core part of the algorithm. It's a diffusion
> step, this gets called 3 times and in total this takes up more than
> one second of cpu time on my machine which makes framerates very
> slow. If anyone got any improve
On Jan 14, 8:27 am, Asbjørn Bjørnstad wrote:
> Anyway, here is a core part of the algorithm. It's a diffusion
> step, this gets called 3 times and in total this takes up more than
> one second of cpu time on my machine which makes framerates very
> slow. If anyone got any improvements I'd be hap
Asbjxrn,
One thing that leaps out to me performance-wise is the 3 nested loops
(dotimes, dotimes, loop/recur). Whatever's inside the inner loop is
getting run a lot of times! General advice about reducing loop depth
and computation required inside the innermost loop aside... have you
looked at cl
On Jan 14, 12:20 pm, "Mark H." wrote:
> I humbly propose that folks shouldn't complain about Clojure being
> slow for their apps until they have at least one of the following:
>
> 1. A targeted benchmark for an important bottleneck in their
> application, implemented in both Clojure and the cur
Rich, I must apologize-- I worded my question *far* too harshly. I knew
it as I pushed the send button. I am a huge fan of Clojure, and plan to
use it as often as possible. My question was really looking for hints,
so that I can use it in more places. You gave me a great one, thanks!
Is th
For those interested in numeric performance, Clojure lets you use
arrays of primitives, has primitive math support, primitive local
support, and has higher-level macros for dealing with them (amap,
areduce) which can also serve as models for your own. You can also
use :inline to wrap arithmetic pr
Perhaps this thread is dead, but have you looked at CUDA?
A modern GPU has around 100 times the FPU firepower compared to a
modern core duo. Whether you can structure your algorithm to suite
the hardware is another question and I could help you with that. CUDA
isn't as strong on integer but the
I humbly propose that folks shouldn't complain about Clojure being
slow for their apps until they have at least one of the following:
1. A targeted benchmark for an important bottleneck in their
application, implemented in both Clojure and the current
implementation language, with performance res
On Jan 12, 10:21 am, Stuart Sierra
wrote:
> If you have
> highly-optimized, custom-designed numerical algorithms written in a
> low-level language like C++, you will never be able to write a version
> that is equally fast in a dynamic, virtual-machine language.
I wouldn't say "never"; clearly Cl
On Jan 13, 4:41 am, "Eric Lavigne" wrote:
> > > There's also the (in)famous language benchmark
> > > site:http://shootout.alioth.debian.org/
>
> > This is primarily what I was going on. I realize no
> > benchmarking approach is going to be perfect, but
> > this attempt doesn't seem too bad. I
On Jan 13, 4:30 am, Mark P wrote:
> On Jan 13, 5:49 pm, Zak Wilson wrote:
>
> > You're probably thinking of
> > this:http://www.flownet.com/gat/papers/lisp-java.pdf
>
> Thanks for the link.
>
> > There's also the (in)famous language benchmark
> > site:http://shootout.alioth.debian.org/
>
> Th
On Jan 13, 10:07 am, cliffc wrote:
> Some comments:
>
> 1- If you think that HotSpot/Java is slower than C++ by any
> interesting amount, I'd love to see the test case. Being the
> architect of HotSpot "-server" I've a keen interest in where
> performance isn't on par with C.
-snip-
> 5- T
Why is Clojure slower than Java? And, can it be fixed? Is it just the
dynamic lookups?
I also want to use Clojure in my work to implement the inner loops, but
I was disappointed by a previous discussion looking at the speed of
Clojure. As I recall Clojure seems to be about 1/4 the speed of
Some comments:
1- If you think that HotSpot/Java is slower than C++ by any
interesting amount, I'd love to see the test case. Being the
architect of HotSpot "-server" I've a keen interest in where
performance isn't on par with C. Except for a handful of specialized
uses (e.g. high-level interpr
On Jan 11, 9:41 pm, Mark P wrote:
> The programs I write perform applied mathematical
> optimization (using mainly integer arithmetic)
> and often take hours (occasionally even days)
> to run. So even small percentage improvements
> in execution speed can make a significant
> practical differenc
On Jan 13, 2009, at 14:04, Mark P wrote:
> Then what do people mean when they say that lisp blurs
> the distinction between compile-time and run-time?
I don't know. I can only guess that they may be referring to the fact
that many Lisp dialects have both an interpreter and a compiler. Or
to
> A macro cannot depend on runtime information. A macro is a function
> that is called at compile time, its argument is an expression (as
> written by the programmer, or as returned by another macro), and its
> result is a modified expression. There is no way a macro could access
> runtime
>
>
> > There's also the (in)famous language benchmark
> > site:http://shootout.alioth.debian.org/
>
> This is primarily what I was going on. I realize no
> benchmarking approach is going to be perfect, but
> this attempt doesn't seem too bad. Is there any
> reason to be particularly sceptical ab
On Jan 13, 5:49 pm, Zak Wilson wrote:
> You're probably thinking of
> this:http://www.flownet.com/gat/papers/lisp-java.pdf
Thanks for the link.
> There's also the (in)famous language benchmark
> site:http://shootout.alioth.debian.org/
This is primarily what I was going on. I realize no
bench
On Jan 13, 2009, at 12:30, Mark P wrote:
>> Macros are handled at compile time, so they add no run-time overhead.
>
> But isn't "compile time" sometimes _at_ runtime? Ie, if
> a macro is dependent on runtime information, then isn't
> it passed to "the compiler" which is included as part of
> the
> I am not aware of any auto-parallelizing compiler that is actually
> useful in practice.
Good to know - thanks.
> > And this leads to another question I have about Lisp-style
> > languages in general. I get the impression that in Lisp
> > much of the "compiler" is Lisp code itself. Ie, lay
On 13.01.2009, at 05:35, Mark P wrote:
> I know that there are other functional approaches where
> the compiler automatically finds ways to parallelize. Is there
> much scope for this in Clojure? Or is it all pretty much
> manually added concurrency?
I am not aware of any auto-parallelizing co
You're probably thinking of this:
http://www.flownet.com/gat/papers/lisp-java.pdf
There's also the (in)famous language benchmark site:
http://shootout.alioth.debian.org/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Grou
Lisps are not inherently slow. SBCL, Clojure and several Schemes are
all much faster than most popular high-level languages (e.g. Python,
Perl, Ruby...) while being at least as high-level.
Optimized code in SBCL may only be marginally slower than C when type
declarations are used properly. The co
There's a study someone did that compared C++, Java, and Lisp
implementations of various problems. It could be urban legend, but how I
remember it:
The best C++ implementation was the fastest for each problem.
But the average lisp implementation was faster then the average java or C++
implementat
On Jan 13, 1:21 am, Stuart Sierra wrote:
> If you have
> highly-optimized, custom-designed numerical algorithms written in a
> low-level language like C++, you will never be able to write a version
> that is equally fast in a dynamic, virtual-machine language.
I think you are essentially right (
> JNA might be an alternative to JNI:https://jna.dev.java.net/
> But I wouldn't know; haven't used either.
Thanks for this info. It sounds like JNA may be worth
looking into.
Cheers,
Mark.
--~--~-~--~~~---~--~~
You received this message because you are subscrib
> It all depends on your algorithms and your code. Clojure has lots of
> support (data structures and algorithms) for concurrent programming,
> but you have to choose and combine them yourself to get efficient
> parallelization.
I know that there are other functional approaches where
the co
Okay, I'm one of Clojure's biggest fans, and probably one of a very
few using it regularly at work. But let me attempt to inject some
reality into the discussion. The big advantages of Clojure are
succinctness and expressiveness within a Java environment. If you have
highly-optimized, custom-desig
This might help: java libraries for fast computing. I guess they will
be usable from within clojure as well.
http://acs.lbl.gov/~hoschek/colt/
Welcome to the Colt Project. Colt provides a set of Open Source
Libraries for High Performance Scientific and Technical Computing in
Java.
Scientific an
On Mon, Jan 12, 2009 at 6:41 AM, Mark P wrote:
> 1. Some of the algorithms I use have the potential
> to be parallelized. I am hoping that as the number
> of cores in PCs increase, at some point Clojure's
> performance will beat C++'s due to Clojure's
> superior utilization of multiple cores. (
On 12.01.2009, at 06:41, Mark P wrote:
> 1. Some of the algorithms I use have the potential
> to be parallelized. I am hoping that as the number
> of cores in PCs increase, at some point Clojure's
> performance will beat C++'s due to Clojure's
> superior utilization of multiple cores. (Any idea
I can't speak for clojure, so I'm interested in seeing how people who can
will answer.
There's so much to consider. I've heard Haskell is getting faster and has
(or will have) parallel programming under the scenes (automatically doing
independent parts of operations). There are other fast functi
I have recently found out about Clojure and am
rather impressed. I am seriously considering
whether Clojure is a viable language for use at
work. The main stumbling block would be if
performance (both speed and memory) turns out
to be insufficent. I currently use C++, but I'd love
to be able to
46 matches
Mail list logo
