Re: Why is this code so slow?

[Sung Pae]

On Sat, Feb 02, 2013 at 06:28:09PM -0800, Alexandros Bantis wrote:

> Hello all. I'm working through the Project Euler problems in Java,
> Scala, & Clojure (trying to learn all three?!?). I notice that for one
> particular problem, I use--more or less--a similar algorithm for all
> three, but the clojure code runs about 20-30 times slower than the
> java/scala versions. Does anyone have any idea why this might be? It
> strikes me that it might have something to do with every? but I don't
> know because I'm a newbie with Clojure.

Daniel Solano Gómez gave a very interesting talk last summer about
numerical performance in Clojure:

http://www.infoq.com/presentations/Crunching-Numbers-Clojure

While there are many technical tips about boosting math performance,
Daniel's overarching point is that the best speed boost is the _right
algorithm_. For instance, this solution to the problem runs in ~2ms:

```

(def primes
  "This should be a lazy-seq of primes generated by a bit-sieve, but for
   this example the largest prime we need is 3!"
  [2 3])

(defn prime-factors [n]
  (loop [n n fs []]
(if-let [p (first (for [p primes
:while (<= p (int (Math/sqrt n)))
:when (zero? (rem n p))]
p))]
  (recur (/ n p) (conj fs p))
  (conj fs n

(defn lcm
  "The lowest common multiple of a set of numbers is the product of the
   distinct prime factors in the set each raised to the power of the
   greatest occurence in a single number."
  [& xs]
  (let [fqs (map #(frequencies (prime-factors %)) xs)]
(apply * (map (fn [p] (Math/pow p (apply max (map #(get % p 0) fqs
  (set (mapcat keys fqs))

(time
  (long (apply lcm (range 2 21

"Elapsed time: 2.010032 msecs"
232792560

```

I know you are explicitly asking for language implementation
differences, but I believe you would be better served in this instance
by studying more elegant algorithms.

The fastest code in any language is the code that does not execute;
designing with this in mind is especially important in Clojure, where
the functional abstractions are beautiful, but somewhat costly.

guns

-- 
-- 
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.

Re: Why is this code so slow?

[Shantanu Kumar]

On Feb 3, 11:40 pm, Alexandros Bantis  wrote:
> yes, I believe I can just make a list of the greatest common factors and
> then multiply them out to get the number rather than iterating through 2
> through n. Still, I'm curious about the performance difference, since
> all three are running on the same JVM and ultimately are all compiled
> down to java byte code, you would expect that a similar algorithm would
> produce similar results across the three.

I ran both provided Java code and my Clojure code (defaulting to (int
n) just like the Java version) with JVM `-server` option and. It made
no difference to the Java version at 18s, but the Clojure version came
down to 22s. This is probably because JIT inlining is more effective
in the -server mode and Clojure's primitive support depends on
inlining for performance: http://clojure.org/news

Shantanu

-- 
-- 
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.

Re: Why is this code so slow?

[Alexandros Bantis]

yes, I believe I can just make a list of the greatest common factors and 
then multiply them out to get the number rather than iterating through 2 
through n. Still, I'm curious about the performance difference, since 
all three are running on the same JVM and ultimately are all compiled 
down to java byte code, you would expect that a similar algorithm would 
produce similar results across the three.


On 02/03/2013 07:29 AM, Jules wrote:

If your goal is just to make it fast, then you should use a different
 algorithm, e.g.

(defn bump-up "Bump up n by a multiple of x until greater than or
equal to k." [n x k] (if (>= n k) n (recur (+ n x) x k)))

(defn bump-up-fast "Bump up n by a multiple of x until greater than
or equal to k in O(1)." [n x k] )

(defn lcm "Compute the least common multiple of a and b." [a b] (loop
[n a k b] (cond (< n k) (recur (bump-up n a k) k) (> n k) (recur n
(bump-up k b n)) (= n k) n)))

(defn smallest-multiple-of-1-to-n [n] (reduce lcm (range 1 (+ n
1

On Sunday, February 3, 2013 3:28:09 AM UTC+1, Alexandros Bantis
wrote:

Hello all. I'm working through the Project Euler problems in Java,
Scala, & Clojure (trying to learn all three?!?). I notice that for
one particular problem, I use--more or less--a similar algorithm for
all three, but the clojure code runs about 20-30 times slower than
the java/scala versions. Does anyone have any idea why this might be?
It strikes me that it might have something to do with every? but I
don't know because I'm a newbie with Clojure.

http://stackoverflow.com/questions/14668272/what-can-i-do-to-speed-up-this-code







thanks,

alex

-- -- 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.




--
--
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.

Re: Why is this code so slow?

[Curtis Gagliardi]

Was on clojure 1.4, just tried on 1.5.0-RC4 and its a few hundred 
miliseconds faster in its own 
function.  

4921.78197 msecs vs  5251.267893 msecs

On Sunday, February 3, 2013 11:52:11 AM UTC-6, Curtis Gagliardi wrote:
>
> >>For some reason, by splitting out the inner loop into a function 
> >>shaved 6 more seconds (from 34s to 28s) on my low-config 32-bit 
> >>laptop: 
>
> Pulling every-d? out into it's own function slowed things down a few 
> seconds for me.  Strange stuff.

-- 
-- 
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.

Re: Why is this code so slow?

[Curtis Gagliardi]

>>For some reason, by splitting out the inner loop into a function 
>>shaved 6 more seconds (from 34s to 28s) on my low-config 32-bit 
>>laptop: 

Pulling every-d? out into it's own function slowed things down a few 
seconds for me.  Strange stuff.

-- 
-- 
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.

Re: Why is this code so slow?

[Jules]

If your goal is just to make it fast, then you should use a different 
algorithm, e.g.

(defn bump-up
  "Bump up n by a multiple of x until greater than or equal to k." 
  [n x k]
  (if (>= n k) n (recur (+ n x) x k)))

(defn bump-up-fast
  "Bump up n by a multiple of x until greater than or equal to k in O(1)."
  [n x k]
  )

(defn lcm
  "Compute the least common multiple of a and b."
  [a b]
  (loop [n a k b]
(cond 
  (< n k) (recur (bump-up n a k) k)
  (> n k) (recur n (bump-up k b n))
  (= n k) n)))

(defn smallest-multiple-of-1-to-n
  [n]
  (reduce lcm (range 1 (+ n 1

On Sunday, February 3, 2013 3:28:09 AM UTC+1, Alexandros Bantis wrote:
>
> Hello all. I'm working through the Project Euler problems in Java, 
> Scala, & Clojure (trying to learn all three?!?). I notice that for one 
> particular problem, I use--more or less--a similar algorithm for all 
> three, but the clojure code runs about 20-30 times slower than the 
> java/scala versions. Does anyone have any idea why this might be? It 
> strikes me that it might have something to do with every? but I don't 
> know because I'm a newbie with Clojure. 
>
>
> http://stackoverflow.com/questions/14668272/what-can-i-do-to-speed-up-this-code
>  
>
> thanks, 
>
> alex 
>

-- 
-- 
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.

Re: Why is this code so slow?

[Dennis Haupt]

without looking at the code:
ranges in scala have been optimized in i think 2.10 to be able to be
inlineable completely when you iterate over them. at runtime, it
*should* be equal to a simple while loop and a counter variable

Am 03.02.2013 14:28, schrieb Jules:
> The Scala version is probably faster because it uses a range (1 to top)
> which is represented as a pair of integers (the start and endpoint).
> Perhaps the JVM can even eliminate that completely with escape analysis.
> The Java version is repeatedly filling an ArrayList with the numbers in
> that range.
> 
> On Sunday, February 3, 2013 12:19:51 PM UTC+1, Casper Clausen wrote:
> 
> Given that I don't know much about how scala does optimizations, I
> find the question of why the scala version is faster than the Java
> version even more interesting.
> 
> It seems to me that in Scala, the list (don't know the actual data
> type which is created) of 1 to 20 is created each
> time isDivisibleByAll is called which (probably?) creates some
> overhead. 
> 
> The Java version doesn't create the list for each check, but it uses
> an ArrayList where it could use an array and Integer where it could
> use int - shenedu makes that optimization in the buttom, but it only
> improves about half a second according to him.
> 
> So what's going on the Scala version?
> 
> On Sunday, February 3, 2013 3:28:09 AM UTC+1, Alexandros Bantis wrote:
> 
> Hello all. I'm working through the Project Euler problems in Java,
> Scala, & Clojure (trying to learn all three?!?). I notice that
> for one
> particular problem, I use--more or less--a similar algorithm for
> all
> three, but the clojure code runs about 20-30 times slower than the
> java/scala versions. Does anyone have any idea why this might
> be? It
> strikes me that it might have something to do with every? but I
> don't
> know because I'm a newbie with Clojure.
> 
> 
> http://stackoverflow.com/questions/14668272/what-can-i-do-to-speed-up-this-code
> 
> 
> 
> 
> thanks,
> 
> alex
> 
> -- 
> -- 
> 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.
>  
>  


-- 

-- 
-- 
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.

Re: Why is this code so slow?

[Jules]

The Scala version is probably faster because it uses a range (1 to top) 
which is represented as a pair of integers (the start and endpoint). 
Perhaps the JVM can even eliminate that completely with escape analysis. 
The Java version is repeatedly filling an ArrayList with the numbers in 
that range.

On Sunday, February 3, 2013 12:19:51 PM UTC+1, Casper Clausen wrote:
>
> Given that I don't know much about how scala does optimizations, I find 
> the question of why the scala version is faster than the Java version even 
> more interesting.
>
> It seems to me that in Scala, the list (don't know the actual data type 
> which is created) of 1 to 20 is created each time isDivisibleByAll is 
> called which (probably?) creates some overhead. 
>
> The Java version doesn't create the list for each check, but it uses an 
> ArrayList where it could use an array and Integer where it could use int - 
> shenedu makes that optimization in the buttom, but it only improves about 
> half a second according to him.
>
> So what's going on the Scala version?
>
> On Sunday, February 3, 2013 3:28:09 AM UTC+1, Alexandros Bantis wrote:
>>
>> Hello all. I'm working through the Project Euler problems in Java, 
>> Scala, & Clojure (trying to learn all three?!?). I notice that for one 
>> particular problem, I use--more or less--a similar algorithm for all 
>> three, but the clojure code runs about 20-30 times slower than the 
>> java/scala versions. Does anyone have any idea why this might be? It 
>> strikes me that it might have something to do with every? but I don't 
>> know because I'm a newbie with Clojure. 
>>
>>
>> http://stackoverflow.com/questions/14668272/what-can-i-do-to-speed-up-this-code
>>  
>>
>> thanks, 
>>
>> alex 
>>
>

-- 
-- 
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.

Re: Why is this code so slow?

[Shantanu Kumar]

> Changing (< 0 ...) to (pos? ..) had no noticeable delay.

I meant 'difference', not 'delay'.

Shantanu

-- 
-- 
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.

Re: Why is this code so slow?

[Casper Clausen]

Given that I don't know much about how scala does optimizations, I find the 
question of why the scala version is faster than the Java version even more 
interesting.

It seems to me that in Scala, the list (don't know the actual data type 
which is created) of 1 to 20 is created each time isDivisibleByAll is 
called which (probably?) creates some overhead. 

The Java version doesn't create the list for each check, but it uses an 
ArrayList where it could use an array and Integer where it could use int - 
shenedu makes that optimization in the buttom, but it only improves about 
half a second according to him.

So what's going on the Scala version?

On Sunday, February 3, 2013 3:28:09 AM UTC+1, Alexandros Bantis wrote:
>
> Hello all. I'm working through the Project Euler problems in Java, 
> Scala, & Clojure (trying to learn all three?!?). I notice that for one 
> particular problem, I use--more or less--a similar algorithm for all 
> three, but the clojure code runs about 20-30 times slower than the 
> java/scala versions. Does anyone have any idea why this might be? It 
> strikes me that it might have something to do with every? but I don't 
> know because I'm a newbie with Clojure. 
>
>
> http://stackoverflow.com/questions/14668272/what-can-i-do-to-speed-up-this-code
>  
>
> thanks, 
>
> alex 
>

-- 
-- 
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.

Re: Why is this code so slow?

[Shantanu Kumar]

On Feb 3, 3:54 pm, "Shen, Feng"  wrote:
> > I was able to shave off some more by writing (not= 0 (rem i d)) as (<
>
> 0 (rem i d)).
>
> the running time is about 4787ms on my computer, compare to *2759ms *of the
> java version, a bit slower, but not much.
>
> 沈锋
> 美味书签 :http://meiweisq.com
> 博客：http://shenfeng.me
>
> On Sun, Feb 3, 2013 at 6:42 PM, Shantanu Kumar 
> wrote:
>
>
>
>
>
>
>
>
>
> > On Feb 3, 12:54 pm, Curtis Gagliardi 
> > wrote:
> > > I took your version Feng and used rem instead of mod and added a type
> > hint
> > > and got down from:
> > > 23217.321626 => 11398.389942
>
> > > No idea where to go from here though.  I'm surprised there's such a
> > > difference even not using any sort of collection.
>
> > > (defn smallest-multiple-of-1-to-n-hinted-rem
> > >   [^long n]
> > >   (loop [i n]
> > > (if (loop [d 2]
> > >   (cond (> d n) true
> > > (not= 0 (rem i d)) false
> > > :else (recur (inc d
> > >   i
> > >   (recur (inc i
>
> > I was able to shave off some more by writing (not= 0 (rem i d)) as (<
> > 0 (rem i d)).

For some reason, by splitting out the inner loop into a function
shaved 6 more seconds (from 34s to 28s) on my low-config 32-bit
laptop:

(defn every-d?
  [^long x ^long n]
  (loop [d 2]
(cond (> d n) true
  (< 0 (rem x d)) false
  :otherwise (recur (inc d)

(defn smallest-multiple-of-1-to-n
  [n]
  (let [n (long n)]
(loop [x n]
  (if (every-d? x n)
x
(recur (inc x))

Changing (< 0 ...) to (pos? ..) had no noticeable delay. This is of
course only a micro-benchmark and numbers would probably change when
the JIT compiler kicks in.

With *unchecked-math* set to true, the Clojure version above takes
28s. Interestingly, when I modified the Java version to use Long, the
time went up from 18s to 40s and for unboxed long, the time went up
from 18s to 37s.

Shantanu

-- 
-- 
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.

Re: Why is this code so slow?

[Shen, Feng]

> I was able to shave off some more by writing (not= 0 (rem i d)) as (<
0 (rem i d)).

the running time is about 4787ms on my computer, compare to *2759ms *of the
java version, a bit slower, but not much.


沈锋
美味书签 : http://meiweisq.com
博客： http://shenfeng.me


On Sun, Feb 3, 2013 at 6:42 PM, Shantanu Kumar wrote:

>
>
> On Feb 3, 12:54 pm, Curtis Gagliardi 
> wrote:
> > I took your version Feng and used rem instead of mod and added a type
> hint
> > and got down from:
> > 23217.321626 => 11398.389942
> >
> > No idea where to go from here though.  I'm surprised there's such a
> > difference even not using any sort of collection.
> >
> > (defn smallest-multiple-of-1-to-n-hinted-rem
> >   [^long n]
> >   (loop [i n]
> > (if (loop [d 2]
> >   (cond (> d n) true
> > (not= 0 (rem i d)) false
> > :else (recur (inc d
> >   i
> >   (recur (inc i
>
> I was able to shave off some more by writing (not= 0 (rem i d)) as (<
> 0 (rem i d)).
>
> Shantanu
>
> --
> --
> 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.
>
>
>

-- 
-- 
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.

Re: Why is this code so slow?

[Mark Engelberg]

On Sun, Feb 3, 2013 at 2:42 AM, Shantanu Kumar wrote:

> I was able to shave off some more by writing (not= 0 (rem i d)) as (<
> 0 (rem i d)).
>


Haven't tested, but based on past experience I would expect (not (zero?
(rem i d))) to be the fastest way, or possibly
(pos? (rem i d))

In general, zero?, pos?, and neg? are faster than comparing to 0 with = >
and <.

--Mark

-- 
-- 
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.

Re: Why is this code so slow?

[Shantanu Kumar]

On Feb 3, 12:54 pm, Curtis Gagliardi 
wrote:
> I took your version Feng and used rem instead of mod and added a type hint
> and got down from:
> 23217.321626 => 11398.389942
>
> No idea where to go from here though.  I'm surprised there's such a
> difference even not using any sort of collection.
>
> (defn smallest-multiple-of-1-to-n-hinted-rem
>   [^long n]
>   (loop [i n]
>     (if (loop [d 2]
>           (cond (> d n) true
>                 (not= 0 (rem i d)) false
>                 :else (recur (inc d
>       i
>       (recur (inc i

I was able to shave off some more by writing (not= 0 (rem i d)) as (<
0 (rem i d)).

Shantanu

-- 
-- 
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.

Re: Why is this code so slow?

[Curtis Gagliardi]

I took your version Feng and used rem instead of mod and added a type hint 
and got down from:
23217.321626 => 11398.389942

No idea where to go from here though.  I'm surprised there's such a 
difference even not using any sort of collection.

(defn smallest-multiple-of-1-to-n-hinted-rem
  [^long n]
  (loop [i n]
(if (loop [d 2]
  (cond (> d n) true
(not= 0 (rem i d)) false
:else (recur (inc d
  i
  (recur (inc i

-- 
-- 
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.

Re: Why is this code so slow?

[Feng Shen]

I can only think about a bit faster version:   46555ms => 23846ms for 20

(defn smallest-multiple-of-1-to-n
 [n]
  (let [divisors (range 2 (inc n))]
   (loop [i n]
 (if (loop [d 2]
(cond (> d n) true
  (not= 0 (mod i d)) false
  :else (recur (inc d
 i
 (recur (inc i))


I am not familiar with how Clojure's numeric works.  There should be a 
faster way of doing it in Clojure.

On Sunday, February 3, 2013 10:28:09 AM UTC+8, Alexandros Bantis wrote:
>
> Hello all. I'm working through the Project Euler problems in Java, 
> Scala, & Clojure (trying to learn all three?!?). I notice that for one 
> particular problem, I use--more or less--a similar algorithm for all 
> three, but the clojure code runs about 20-30 times slower than the 
> java/scala versions. Does anyone have any idea why this might be? It 
> strikes me that it might have something to do with every? but I don't 
> know because I'm a newbie with Clojure. 
>
>
> http://stackoverflow.com/questions/14668272/what-can-i-do-to-speed-up-this-code
>  
>
> thanks, 
>
> alex 
>

-- 
-- 
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.

Why is this code so slow?

[Alexandros Bantis]

Hello all. I'm working through the Project Euler problems in Java, 
Scala, & Clojure (trying to learn all three?!?). I notice that for one 
particular problem, I use--more or less--a similar algorithm for all 
three, but the clojure code runs about 20-30 times slower than the 
java/scala versions. Does anyone have any idea why this might be? It 
strikes me that it might have something to do with every? but I don't 
know because I'm a newbie with Clojure.


http://stackoverflow.com/questions/14668272/what-can-i-do-to-speed-up-this-code

thanks,

alex

--
--
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.

Re: Why is this code so slow?

[Dmitry Gutov]

Clojure 1.2.1 here.

4e6 takes about 10 seconds, the process uses ~500Mb of RAM. `lein
repl` is fine with that.
Python takes 5, but that's acceptable difference, I think, considering
we're talking immutable vs mutable here.

If you still have the old code, I'd like to take a look.

On Jul 25, 10:54 am, Oskar  wrote:
> On Jul 23, 4:06 pm, Dmitry Gutov  wrote:
>
> > Ahem.
>
> > Here is a more idiomatic version that runs under half a second, no
> > annotations required.
>
> I did that from the beginning, but as I really needed 4e6 and not 1e5
> elements, that map got very big. And I didn't remember the argument to
> give java more memory. Also I was just curious to see what arrays did
> to the performance. However, my code that looked like that was slow
> too. I used Clojure 1.2.0. Are you using 1.3.0?

-- 
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

Re: Why is this code so slow?

[Oskar]

On Jul 23, 4:06 pm, Dmitry Gutov  wrote:
> Ahem.
>
> Here is a more idiomatic version that runs under half a second, no
> annotations required.

I did that from the beginning, but as I really needed 4e6 and not 1e5
elements, that map got very big. And I didn't remember the argument to
give java more memory. Also I was just curious to see what arrays did
to the performance. However, my code that looked like that was slow
too. I used Clojure 1.2.0. Are you using 1.3.0?


> (def vs (atom {}))
>
> (defn sk [k]
>   (if (@vs k)
>       (@vs k)
>       (let [ans (if (< k 56)
>                   (- (mod (+ 13 (- (* k 23)) (* 37 k k k))
>                           100) 50)
>                   (- (mod (+ (sk (- k 24))
>                              (sk (- k 55))) 100)
>                      50))]
>         (do (swap! vs assoc k ans)
>             ans
>
> user> (reset! vs {})
> {}
> user> (time (dorun (map sk (range 10
> "Elapsed time: 155.082351 msecs"
> nil
>
> I guess the moral is that the built-in data structures are quite fast,
> and reflection is evil.

-- 
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

Re: Why is this code so slow?

[Dmitry Gutov]

Ahem.

Here is a more idiomatic version that runs under half a second, no
annotations required.

(def vs (atom {}))

(defn sk [k]
  (if (@vs k)
  (@vs k)
  (let [ans (if (< k 56)
  (- (mod (+ 13 (- (* k 23)) (* 37 k k k))
  100) 50)
  (- (mod (+ (sk (- k 24))
 (sk (- k 55))) 100)
 50))]
(do (swap! vs assoc k ans)
ans

user> (reset! vs {})
{}
user> (time (dorun (map sk (range 10
"Elapsed time: 155.082351 msecs"
nil

I guess the moral is that the built-in data structures are quite fast,
and reflection is evil.

-- 
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

Re: Why is this code so slow?

[Dmitry Gutov]

Sorry, I overlooked the fact that the function checks if the value is
cached at the top, so, with the way you're running the benchmark, the
recursive calls don't result in more recursive calls.
Eliminating them gives performance increase of about 30%, but that's
nothing compared to adding annotations.

On Jul 23, 7:02 am, Oskar  wrote:
> Thanks for the replies everyone!
>
> About the Python version not being recursive: Oh yeah, didn't even
> think about that, but it shouldn't matter that much, or? With all the
> right type hints the clojure version should be much faster than the
> previous one even with recursion, right?
>
> On Jul 22, 10:51 pm, Dmitry Gutov  wrote:
>
>
>
>
>
>
>
> > In case the two replies above didn't drive the point home, the Python
> > version is not recursive (it uses results memoized in the data array).
> > So, not the same thing.

-- 
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

Re: Why is this code so slow?

[Sean Corfield]

FWIW, out of the box on Clojure 1.3.0 with no changes at all, your
code took about 8 seconds on my machine on the first run. Since your
sk function will reuse the arrays, subsequent runs don't calculate any
new values, they just return the pre-calculated ones. Subsequent runs
took about 2 seconds on my machine.

I took David's version and ran that on Clojure 1.3.0 with about the
same results as he saw. Even naming the anonymous function and using
recursive calls (instead of the aget vs substitution that David did)
produced reasonable results (closer to 400ms instead of closer to
300ms) - just to address Ken's comment since the ss / vs arrays
essentially memoize the calls, even in your original code.

Out of curiosity, I modified David's version to pull the array creation out:

(def skk (sk (long-array 401) (boolean-array 401)))
(time (dorun (map skk (range 10

First run, same (as expected). Subsequent runs (only retrieving
numbers, not calculating them), about 10ms.

Eliminating reflection and using unchecked math are going to get you
some pretty darn fast Clojure code!

Sean

On Thu, Jul 21, 2011 at 6:32 AM, Oskar  wrote:
> I was doing some project euler problems and I wrote the following
> code. It is really slow, and I would like to know why and how it can
> be made faster. Not that I care much about this code in particular,
> but I want to understand Clojure better.
>
>    (def vs (int-array 401))
>    (def ss (boolean-array 401))
>
>    (defn sk [k]
>      (if (aget ss k)
>        (aget vs k)
>        (let [ans
>              (if (< k 56)
>                (- (mod (+ 13 (- (* k 23)) (* 37 k k k))
> 100) 50)
>                (- (mod (+ (sk (- k 24)) (sk (- k 55))) 100)
> 50))]
>          (do (aset vs k ans) (aset ss k true) ans
>
>    (time (dorun (map sk (range 10
>
> The call above takes 20 seconds, which is surprisingly slow (at least
> to me). The "same thing" in Python it takes under under 1 (not sure
> exactly how long). Why so slow?

-- 
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

Re: Why is this code so slow?

[Ken Wesson]

On Fri, Jul 22, 2011 at 11:02 PM, Oskar  wrote:
> Thanks for the replies everyone!
>
> About the Python version not being recursive: Oh yeah, didn't even
> think about that, but it shouldn't matter that much, or? With all the
> right type hints the clojure version should be much faster than the
> previous one even with recursion, right?

How many times does the recursive version recalculate, say, (sk 1)? It
calculates (sk 1). Later it reaches (sk 56) which calculates (sk 1)
again. Then (sk 80) recalculates (sk 56) which recalculates (sk 1),
and (sk 111) does likewise, while (sk 104) recalculates (sk 80), which
recalculates (sk 56) ...

So, the answer to your question is "probably not". :)

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

-- 
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

Re: Why is this code so slow?

[Oskar]

Thanks for the replies everyone!

About the Python version not being recursive: Oh yeah, didn't even
think about that, but it shouldn't matter that much, or? With all the
right type hints the clojure version should be much faster than the
previous one even with recursion, right?

On Jul 22, 10:51 pm, Dmitry Gutov  wrote:
> In case the two replies above didn't drive the point home, the Python
> version is not recursive (it uses results memoized in the data array).
> So, not the same thing.

-- 
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

Re: Why is this code so slow?

[Dmitry Gutov]

In case the two replies above didn't drive the point home, the Python
version is not recursive (it uses results memoized in the data array).
So, not the same thing.

-- 
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

Re: Why is this code so slow?

[David Nolen]

(set! *warn-on-reflection* true)
(set! *unchecked-math* true)

(defn sk [^longs vs ^booleans ss]
  (fn ^long [^long k]
(if (aget ss k)
  (aget vs k)
  (let [ans (if (< k 56)
  (- (mod (+ 13 (- (* k 23)) (* 37 k k k))
  100) 50)
  (- (mod (+ (aget vs (- k 24))
 (aget vs (- k 55))) 100)
 50))]
(do (aset vs k (long ans))
(aset ss k true)
ans)

(comment
 (time
  (dorun
   (map (sk (long-array 401)
(boolean-array 401))
(range 10
 )

Not sure if this preserves your code. On my machine running 1.3.0-beta1 this
takes 300-400ms once the JVM has warmed up.

David

-- 
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

Re: Why is this code so slow?

[Ken Wesson]

On Thu, Jul 21, 2011 at 9:32 AM, Oskar  wrote:
> Hi!
>
> I was doing some project euler problems and I wrote the following
> code. It is really slow, and I would like to know why and how it can
> be made faster. Not that I care much about this code in particular,
> but I want to understand Clojure better.
>
>    (def vs (int-array 401))
>    (def ss (boolean-array 401))
>
>    (defn sk [k]
>      (if (aget ss k)
>        (aget vs k)
>        (let [ans
>              (if (< k 56)
>                (- (mod (+ 13 (- (* k 23)) (* 37 k k k))
> 100) 50)
>                (- (mod (+ (sk (- k 24)) (sk (- k 55))) 100)
> 50))]
>          (do (aset vs k ans) (aset ss k true) ans
>
>    (time (dorun (map sk (range 10
>
> The call above takes 20 seconds, which is surprisingly slow (at least
> to me). The "same thing" in Python it takes under under 1 (not sure
> exactly how long). Why so slow?

I'd guess boxed arithmetic. But first you might want to look into
memoizing sk and making the recursive calls use the memoized version.

If that doesn't make it fast enough, try using Clojure 1.3 (if you
aren't already) and using primitives in sk including for its arguments
and return value.

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

-- 
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

Why is this code so slow?

[Oskar]

Hi!

I was doing some project euler problems and I wrote the following
code. It is really slow, and I would like to know why and how it can
be made faster. Not that I care much about this code in particular,
but I want to understand Clojure better.

(def vs (int-array 401))
(def ss (boolean-array 401))

(defn sk [k]
  (if (aget ss k)
(aget vs k)
(let [ans
  (if (< k 56)
(- (mod (+ 13 (- (* k 23)) (* 37 k k k))
100) 50)
(- (mod (+ (sk (- k 24)) (sk (- k 55))) 100)
50))]
  (do (aset vs k ans) (aset ss k true) ans

(time (dorun (map sk (range 10

The call above takes 20 seconds, which is surprisingly slow (at least
to me). The "same thing" in Python it takes under under 1 (not sure
exactly how long). Why so slow?

The python version I tried:

data = [None]*401

def sk(k):
if data[k] is None:
if k <= 55:
ans = ((13 - 23 * k + 37 *
k**3) % 100) - 50
else:
ans = ((data[k-24] + data[k-55] + 100)
% 100) - 50
data[k] = ans
return ans
else:
return data[k]

a = map(sk, range(10)) ; almost instant

-- 
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

Re: Why is this code so slow?

[Nebojsa Stricevic]

Thanks a lot for the tips. It works great now!

-- 
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

Re: Why is this code so slow?

[ataggart]

Small things (read: I didn't notice any performance change in my
tests)...

You can also pull the (. Math sqrt number) into the let binding so
it's not calculated every time the anonymous function is called.

Also the reduce call in no-dividers? doesn't short-circuit when it
hits a false.  I'd instead use (every? #(pos? (rem number %)) divs).

-- 
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

Re: Why is this code so slow?

[ataggart]

Changing (concat primes [k])  to (conj primes k) gave me an order of
magnitude performance increase.


On Jan 24, 1:19 pm, Nebojsa Stricevic 
wrote:
> Greetings,
>
> I'm new to Clojure and working my way through Project Euler problems
> for learning. I stuck with problem 7, not with solution, but with
> performance. My code needs about 90sec to find solution.
>
> (ns problem7)
>
> (defn no-dividers?
>         "checks if number can be divided with any of dividers"
>         [number dividers]
>         (let [divs (take-while #(<= % (. Math sqrt number)) dividers)]
>                 (reduce #(and %1 (pos? (rem number %2)))
>                                                 true
>                                                 divs)))
>
> (defn find-primes [n]
>         "finds first n primes"
>         (loop [primes [2 3] x 1 f -]
>                 (if (= (count primes) n)
>                         primes
>                         (let [k (f (* 6 x) 1)]
>                                 (recur
>                                         (if (no-dividers? k primes) (concat 
> primes [k]) primes)
>                                         (if (= f -) x (inc x))
>                                         (if (= f -) + -))
>
> (find-primes 10001)
>
> And, for example, this code is much faster:
>
> (defn div? [n d]
>   (= 0 (rem n d)))
>
> (defn smallest-prime-factor [number]
>   (loop [n number d 2]
>     (cond (> d (int (Math/sqrt number))) n
>           (= n d) n
>           (div? n d) d
>           true (recur n (inc d)
>
> (def primes (lazy-cat '(2 3)
>                       (filter #(= %1 (smallest-prime-factor %1))
>                               (take-nth 2 (iterate inc 5)
>
> (nth primes 10001)
>
> Now, since i have advanced a bit in reading about Clojure, I know that
> preferred solution would be by using lazy sequences, but my concern is
> about performance of my solution, no mater how bad is with style.
>
> I should probably say that my background is pure imperative (mostly
> Java, C/C++...).
>
> Thanks in advance.

-- 
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

Why is this code so slow?

[Nebojsa Stricevic]

Greetings,

I'm new to Clojure and working my way through Project Euler problems
for learning. I stuck with problem 7, not with solution, but with
performance. My code needs about 90sec to find solution.

(ns problem7)

(defn no-dividers?
"checks if number can be divided with any of dividers"
[number dividers]
(let [divs (take-while #(<= % (. Math sqrt number)) dividers)]
(reduce #(and %1 (pos? (rem number %2)))
true
divs)))

(defn find-primes [n]
"finds first n primes"
(loop [primes [2 3] x 1 f -]
(if (= (count primes) n)
primes
(let [k (f (* 6 x) 1)]
(recur
(if (no-dividers? k primes) (concat 
primes [k]) primes)
(if (= f -) x (inc x))
(if (= f -) + -))

(find-primes 10001)

And, for example, this code is much faster:

(defn div? [n d]
  (= 0 (rem n d)))

(defn smallest-prime-factor [number]
  (loop [n number d 2]
(cond (> d (int (Math/sqrt number))) n
  (= n d) n
  (div? n d) d
  true (recur n (inc d)

(def primes (lazy-cat '(2 3)
  (filter #(= %1 (smallest-prime-factor %1))
  (take-nth 2 (iterate inc 5)

(nth primes 10001)

Now, since i have advanced a bit in reading about Clojure, I know that
preferred solution would be by using lazy sequences, but my concern is
about performance of my solution, no mater how bad is with style.

I should probably say that my background is pure imperative (mostly
Java, C/C++...).

Thanks in advance.

-- 
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