Stefan, how do these numbers compare to RC1? Is RC2 better than RC1?
On Saturday, March 22, 2014 7:32:53 AM UTC-5, Stefan Kamphausen wrote:
Hi,
On Saturday, March 22, 2014 3:52:00 AM UTC+1, Alex Miller wrote:
That's pretty weird.
that's pretty true.
1.6.0-RC2 is out now - I would
You've piqued my curiosity. Could I trouble you to post the benchmark
results on -RC2 with 96f5b5bdc reverted?
On Friday, March 21, 2014 7:47:00 PM UTC-4, Stefan Kamphausen wrote:
On Saturday, March 22, 2014 12:41:55 AM UTC+1, Andy Fingerhut wrote:
That is odd. This is a shot in the
On Sunday, March 23, 2014 6:02:26 PM UTC+1, Alex Miller wrote:
Stefan, how do these numbers compare to RC1? Is RC2 better than RC1?
If my tests can be trusted, there is an improvement between RC1 and RC2,
but it is still worse than 1.5.1.
*Version* *Java Version* *User time(s)* *Sys
Hi,
Additionally differences in -XX:+PrintCompilation ouput might be
interesting.
first, I tested with -XX:+PrintInlining and there actually is a difference
for seqFrom: in 1.5.1 there are more occurrences of this function in the
output (see data at the end of this post). Since the
Hi,
On Saturday, March 22, 2014 3:52:00 AM UTC+1, Alex Miller wrote:
That's pretty weird.
that's pretty true.
1.6.0-RC2 is out now - I would really appreciate it if you could give it a
shot.
Sure. Tried with Oracle JDK 7 and 8, each run two times and took the
average. Each run
On 22 March 2014 00:47, Stefan Kamphausen ska2...@gmail.com wrote:
On Saturday, March 22, 2014 12:41:55 AM UTC+1, Andy Fingerhut wrote:
That is odd. This is a shot in the dark, and probably unhelpful because I
do not know a good way to verify whether my guess is true, but perhaps the
seqFrom
Hi,
after two days of git bisecting and running my tests over and over again, I
give up. While I can repeatedly identify the commit which causes the
biggest slowdown for me between the 1.5.1 tag and 1.6.0 RC1 I simply refuse
to believe that the result of my analysis is correct.
On
That is odd. This is a shot in the dark, and probably unhelpful because I
do not know a good way to verify whether my guess is true, but perhaps the
seqFrom method went from being small enough to be inlined by your JIT
before that change, to being too large to consider for inlining after the
On Saturday, March 22, 2014 12:41:55 AM UTC+1, Andy Fingerhut wrote:
That is odd. This is a shot in the dark, and probably unhelpful because I
do not know a good way to verify whether my guess is true, but perhaps the
seqFrom method went from being small enough to be inlined by your JIT
That's pretty weird.
1.6.0-RC2 is out now - I would really appreciate it if you could give it a
shot.
Alex
On Friday, March 21, 2014 5:51:14 PM UTC-5, Stefan Kamphausen wrote:
Hi,
after two days of git bisecting and running my tests over and over again,
I give up. While I can
On 19 March 2014 21:14, Alex Miller a...@puredanger.com wrote:
Rich just pushed a change to the String hashing to address this. We're
going to grab the string hashcode (which is cached after first call) and
murmur the result of that. This gives us constant time hashcode after first
call with
Yes, agreed.
--
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
case depends on hashCode, not hasheq, so should be unaffected by these changes.
--
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
On Wednesday, March 19, 2014 4:14:38 PM UTC-4, Alex Miller wrote:
Rich just pushed a change to the String hashing to address this. We're
going to grab the string hashcode (which is cached after first call) and
murmur the result of that. This gives us constant time hashcode after first
call
We're vulnerable to this problem anyway as long as hashing is
deterministic, which is why I think it would be cool to use some
universal-hashing-like scheme...
I think Murmur3 actually uses a seed that could be randomized? Not
really safe in the cryptographic sense of the word, but would make
Regarding Michal's comment of using BST (binary search tree)-based
dictionaries, Clojure does already have sorted-maps and sorted-sets that do
this, for comparable keys/elements.
A nice hybrid of the nearly-O(1) typical case of hash maps/sets, and
simultaneously protecting against the cases where
In case it isn't clear, I don't think such drastic changes could ever hope
to be done in a reasonable time frame for Clojure 1.6.0. Probably better
to have a different thread for this if there is interest in discussing it.
Andy
On Thu, Mar 20, 2014 at 10:03 AM, Andy Fingerhut
On Thursday, March 20, 2014 11:56:46 AM UTC-5, Michał Marczyk wrote:
We're vulnerable to this problem anyway as long as hashing is
deterministic, which is why I think it would be cool to use some
universal-hashing-like scheme...
Agreed - whether it's the old algorithm or new, it's still
I've got RC1 running in a number of places, all working well.
--
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
hi,
RC1 works well with our largest project. See a 5-8% slow-down but no other
problems.
Regards,
Stefan
--
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
record scratch what's that about performance now?
Is that something definitive and reproducible? And if so, is there any way to
track down a cause?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
I'm guessing it's because of the minor overhead on hashing added with
the move to Murmur3?
Alex Miller writes:
record scratch what's that about performance now?
Is that something definitive and reproducible? And if so, is there any way to
track down a cause?
--
You received this message
I moved to 1.6 two weeks ago for development and have had no problem. I had
to change some tests because they depended on the order of elements if you
seq a hashmap.
On Tuesday, March 18, 2014 3:21:22 PM UTC+1, Alex Miller wrote:
Hello all,
We would love to release Clojure 1.6.0 final
That is the only set of changes that I know of that negatively affect
performance in 1.6.0. However, the absolute differences are quite small and
codes are cached. It's hard for me to conjure a scenario where the
resulting effect is an overall 5-8% slowdown. If this is one, I'd like to
Hashes are cached for Clojure collections, keywords and symbols, but
not for strings.
I wonder if people who report these perf regressions use long string
keys in their maps... For this to explain the regression they'd have
to be looking up the same String objects a lot, of course (else
hashCode
Hi Alex,
the runtime of the program changed from 19 to 20 seconds for one set of
data and from approx 6minutes to 6:30 for another set. To me that is
acceptable.
We are reading a few MB of files into memory, create lots of intermediate
vectors, maps and sets and output up to a few hundred
Hi,
On Wednesday, March 19, 2014 3:55:22 PM UTC+1, Michał Marczyk wrote:
Hashes are cached for Clojure collections, keywords and symbols, but
not for strings.
I wonder if people who report these perf regressions use long string
keys in their maps...
As far as I can see, we have /lots/
Thanks, this is all really useful. I would appreciate any more detailed
info.
On Wednesday, March 19, 2014 10:15:35 AM UTC-5, Stefan Kamphausen wrote:
Hi,
On Wednesday, March 19, 2014 3:55:22 PM UTC+1, Michał Marczyk wrote:
Hashes are cached for Clojure collections, keywords and symbols,
I just tried to build master locally with the new JDK 1.8 on a Mac. I'm
getting a build test failure. Sorry, I don't have time to look into it at the
moment. JDK 1.7 worked fine for me.
[java] clojure.test-clojure.reflect
[java]
[java] java.lang.IllegalArgumentException
On Wednesday, March 19, 2014 4:34:45 PM UTC+1, Alex Miller wrote:
Thanks, this is all really useful. I would appreciate any more detailed
info.
* No atoms, agents, refs
* Almost purely functional plus logging and I/O
* Multi-threaded using latest core.async with thread, no go
* JVisualVM
ASM 4.1 does not work with JDK 1.8 see
http://dev.clojure.org/jira/browse/CLJ-1323
Steve Miner writes:
I just tried to build master locally with the new JDK 1.8 on a Mac. I'm
getting a build test failure. Sorry, I don't have time to look into it at
the moment. JDK 1.7 worked fine for
Moved to this release 3 days ago. Nothing to report, works as expected :)
Thank to everyone for this new release :)
Luc P.
Hello all,
We would love to release Clojure 1.6.0 final soon.
We need your help in checking out the current release candidate - this is
your opportunity to let us
Rich just pushed a change to the String hashing to address this. We're
going to grab the string hashcode (which is cached after first call) and
murmur the result of that. This gives us constant time hashcode after first
call with better distribution for combinations in nested collections. Will
And thanks everyone for giving RC1 a look. You are (collectively) the
fortune in my fortune cookie.
--
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
Hello all,
We would love to release Clojure 1.6.0 final soon.
We need your help in checking out the current release candidate - this is
your opportunity to let us know about problems *before* we release, rather
than after.
Try it via
- Download:
All test passes on my projects! It works fine for me!
Thanks!
2014-03-18 15:21 GMT+01:00 Alex Miller a...@puredanger.com:
Hello all,
We would love to release Clojure 1.6.0 final soon.
We need your help in checking out the current release candidate - this is
your opportunity to let us
Thanks Andrey! You are the wind beneath my wings.
On Tuesday, March 18, 2014 9:28:03 AM UTC-5, Andrey Antukh wrote:
All test passes on my projects! It works fine for me!
Thanks!
2014-03-18 15:21 GMT+01:00 Alex Miller al...@puredanger.com javascript:
:
Hello all,
We would love to
2014-03-18 18:21 GMT+04:00 Alex Miller a...@puredanger.com:
We need your help in checking out the current release candidate - this is
your opportunity to let us know about problems *before* we release, rather
than after.
No issues to report from testing 20+ ClojureWerkz projects on
Thanks Michael! You're the hops in my ale.
On Tuesday, March 18, 2014 12:22:15 PM UTC-5, Michael Klishin wrote:
2014-03-18 18:21 GMT+04:00 Alex Miller al...@puredanger.com javascript:
:
We need your help in checking out the current release candidate - this is
your opportunity to let us
Just tried 1.6.0-RC1 with ClojureScript master. All ClojureScript tests
pass except for one which is due to assumptions about print order
(different now due to hash code changes). Easy enough to fix once 1.6.0
actually ships.
David
On Tue, Mar 18, 2014 at 1:44 PM, Alex Miller
Thanks David! You're the English horn in my symphony.
On Tuesday, March 18, 2014 12:50:04 PM UTC-5, David Nolen wrote:
Just tried 1.6.0-RC1 with ClojureScript master. All ClojureScript tests
pass except for one which is due to assumptions about print order
(different now due to hash code
We had some bugs related to assumed ordering in our code which
1.6.0-RC1 surfaced (https://github.com/puppetlabs/puppetdb/pull/887),
otherwise everything looks good for our project - thanks for all the
hard work on this release.
ken.
On Tue, Mar 18, 2014 at 2:21 PM, Alex Miller
Thanks Ken! You're the cheese on my nachos.
On Tuesday, March 18, 2014 12:45:46 PM UTC-5, Ken Barber wrote:
We had some bugs related to assumed ordering in our code which
1.6.0-RC1 surfaced (https://github.com/puppetlabs/puppetdb/pull/887),
otherwise everything looks good for our project -
I think I found a difference between 1.5.1-1.6.0-RC1.
(compile 'cljs.core) fails with a NPE in 1.6.0-RC1. I realise this isn't
particularly supported
by CLJS, but it still worked in 1.5.1.
https://github.com/frenchy64/clojure-16-fail
Help narrowing this is appreciated.
Thanks,
Ambrose
On
I believe this is because cljs.core defines unsigned-bit-shift-right, which
now conflicts
with clojure.core/unsigned-bit-shift-right (added with 1.6.0).
1.6.0 doesn't seem to break anything here, aside from adding to
clojure.core.
Thanks,
Ambrose
On Wed, Mar 19, 2014 at 3:12 AM, Ambrose
Yeah, that's a thing. I think the name was chosen intentionally to be the
same across those as cljs had it first.
On Tuesday, March 18, 2014 2:29:04 PM UTC-5, Ambrose Bonnaire-Sergeant
wrote:
I believe this is because cljs.core defines unsigned-bit-shift-right,
which now conflicts
with
FYI `mvn test` will fail on core.typed because of this issue.
I believe it otherwise passes.
Ambrose
On Wed, Mar 19, 2014 at 3:45 AM, Alex Miller a...@puredanger.com wrote:
Yeah, that's a thing. I think the name was chosen intentionally to be the
same across those as cljs had it first.
I assume that fixing this is a matter of updating src/clj/cljs/core.clj in
clojurescript to exclude unsigned-bit-shift-right?
On Tuesday, March 18, 2014 2:52:03 PM UTC-5, Ambrose Bonnaire-Sergeant
wrote:
FYI `mvn test` will fail on core.typed because of this issue.
I believe it otherwise
Yep, we'll get rid of it once 1.6.0 actually ships.
David
On Tue, Mar 18, 2014 at 5:04 PM, Alex Miller a...@puredanger.com wrote:
I assume that fixing this is a matter of updating src/clj/cljs/core.clj in
clojurescript to exclude unsigned-bit-shift-right?
On Tuesday, March 18, 2014
Tests look good in some of Staples Innovation Labs' projects. Only
failures are ones that assume ordering, which is just an easily correct
failure in the test cases.
On Tue, Mar 18, 2014 at 2:06 PM, David Nolen dnolen.li...@gmail.com wrote:
Yep, we'll get rid of it once 1.6.0 actually ships.
We have 1.6.0-RC1 running in production as of this afternoon. No
problems so far...
Sean
On Tue, Mar 18, 2014 at 7:21 AM, Alex Miller a...@puredanger.com wrote:
Hello all,
We would love to release Clojure 1.6.0 final soon.
We need your help in checking out the current release candidate -
51 matches
Mail list logo
