On Thu, Jan 20, 2011 at 11:57 PM, Mark Engelberg
mark.engelb...@gmail.com wrote:
On Thu, Jan 20, 2011 at 6:51 AM, Andreas Liljeqvist bon...@gmail.com wrote:
I am sorry, I can't seem to reproduce the behavior at the moment :(
Mark, please tell me that I am not delusional...
I definitely
max-key uses destructuring, which was one of the culprits for
unexpectedly holding onto the head of lists before locals clearing was
added.
This part of what I said is garbage, I'm sorry. I looked at max-key
too quickly, but there isn't any destructuring there.
That doesn't change that I
On Fri, Jan 21, 2011 at 6:43 PM, Aaron Cohen aa...@assonance.org wrote:
max-key uses destructuring, which was one of the culprits for
unexpectedly holding onto the head of lists before locals clearing was
added.
This part of what I said is garbage, I'm sorry. I looked at max-key
too quickly,
Running in VisualVM suggests that % of Used Heap is actually very
less. So the problem is that GC isn't running often enough, so the JVM
has to keep allocating more memory.
By problem I meant, in my case, of too much memory consumption.
Odd. I'd expect the JVM to run a GC immediately before
Mbytes.
On Jan 19, 2011, at 5:52 PM, Paul Mooser wrote:
That completes without giving me any error.
I'm using clojure 1.2.0 on OS X 10.6.6, and the JVM is 1.6.0_22.
On Jan 19, 1:42 am, Andreas Liljeqvist bon...@gmail.com wrote:
Reposting this from earlier mail about Euler 14.
(defn cseq [n
This same problem was raised recently:
https://groups.google.com/group/clojure/browse_thread/thread/df4ae16ab0952786?tvc=2q=memory
It isn't a GC problem, it is an issue in the Clojure compiler.
The issue seems to only affect top-level defs. At the top-level:
(reduce + (range 1000))
-
David:
Here is a link to the exact source code of the program I was running
for my recently published results in the sister thread titled Problem
with garbage collection? Was Euler 14.
https://github.com/jafingerhut/clojure-benchmarks/blob/master/collatz/collatz.clj-1.clj
Is this code
Thank you, that explains the failure of the lazy-cseq using top-level defs.
I really hope it gets fixed, Clojure is going to be a hard sell if I have to
explain things like this to my coworkers :(
Anyhow there is still the problem with nonlazy cseq blowing the heap.
(defn cseq [n]
(if (= 1 n)
On Thu, Jan 20, 2011 at 5:04 AM, Andy Fingerhut
andy.finger...@gmail.com wrote:
I would recommend that anyone who publishes their results running this code
specify what OS, JVM, and version of Clojure they are using. I don't know
yet whether OS and JVM version make any difference, but at least
Andreas, How are you running that? Also what do you see in the heap
dump and what is the jvm heap size?
--
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
I am sorry, I can't seem to reproduce the behavior at the moment :(
Mark, please tell me that I am not delusional...
Will try at home also.
2011/1/20 ka sancha...@gmail.com
Andreas, How are you running that? Also what do you see in the heap
dump and what is the jvm heap size?
--
You
On Thu, Jan 20, 2011 at 6:51 AM, Andreas Liljeqvist bon...@gmail.com wrote:
I am sorry, I can't seem to reproduce the behavior at the moment :(
Mark, please tell me that I am not delusional...
I definitely exhausted the heap running your program. I was using
Clojure 1.1, Java 1.6.0_21 with
FWIW, no heap error on my system (Clojure 1.2, Java 1.6.0_13 -server).
--
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
Reposting this from earlier mail about Euler 14.
(defn cseq [n]
(if (= 1 n)
[1]
(cons n (cseq (if (even? n)
(/ n 2)
(+ (* 3 n) 1 ))
(apply max-key count (map cseq (range 1 100)))
Gives a heap error.
cseq is at most 525 elements long.
2011/1/17 Mark
(defn cseq [n]
(if (= 1 n)
[1]
(cons n (cseq (if (even? n)
(/ n 2)
(+ (* 3 n) 1 ))
(apply max-key count (map cseq (range 1 100)))
Gives a heap error.
cseq is at most 525 elements long.
The solution is much more than 525 ( 80). Note that
user (defn cseq [n]
(if (= 1 n)
[1]
(lazy-seq (cons n (cseq (if (even? n)
(/ n 2)
(+ (* 3 n) 1 )))
#'user/cseq
user (count (apply max-key count (map cseq (range 1 100
525
user (first (apply max-key count (map cseq (range 1 100
That completes without giving me any error.
I'm using clojure 1.2.0 on OS X 10.6.6, and the JVM is 1.6.0_22.
On Jan 19, 1:42 am, Andreas Liljeqvist bon...@gmail.com wrote:
Reposting this from earlier mail about Euler 14.
(defn cseq [n]
(if (= 1 n)
[1]
(cons n (cseq (if (even? n
To me this looks totally fine, max-key should keep at most two
sequences in memory. I don't think there should be any difference
between the non-lazy and lazy versions as the depth of cseq is ~500.
The non-lazy version works for me (no heap error) for inputs 1M, 2M,
4M, but for 4M the java
On Wed, Jan 19, 2011 at 6:48 PM, ka sancha...@gmail.com wrote:
Running in VisualVM suggests that % of Used Heap is actually very
less. So the problem is that GC isn't running often enough, so the JVM
has to keep allocating more memory.
Odd. I'd expect the JVM to run a GC immediately before
Hi.
I am using max-key to get the longest sequence from a couple of sequences.
(defn cseq [n]
(if (= 1 n)
[1]
(cons n (cseq (if (even? n)
(/ n 2)
(+ (* 3 n) 1 ))
(apply max-key count (map cseq (range 1 100)))
This gives me a heap error.
To my
Your cseq is not lazy, and some of the sequences can be quite long, so
it wouldn't surprise me if that's the source of your problem.
You can test if this is the problem by doing something like:
(dorun (map cseq (range 1 100))) which removes the max-key from
the computation entirely.
You'll
I don't see why the cseq's have to be lazy, they are at the most 525
elements long.
shouldn't each sequence only be produced when it is reduced in max-key and
then discarded?
But it makes a difference:
(defn cseq [n]
(if (= 1 n)
[1]
(lazy-seq (cons n (cseq (if (even? n)
On Mon, Jan 17, 2011 at 11:55 AM, Andreas Liljeqvist bon...@gmail.com wrote:
I don't see why the cseq's have to be lazy, they are at the most 525
elements long.
shouldn't each sequence only be produced when it is reduced in max-key and
then discarded?
You're right, the chains aren't as long
23 matches
Mail list logo
