These are chat archives for non/algebra

10th
Feb 2015
Erik Osheim
@non
Feb 10 2015 03:36
@tixxit hey did you end up doing that benchmark?
Erik Osheim
@non
Feb 10 2015 05:07
@johnynek, @tixxit another question -- do you all think we should use mapValues ? i'm happy to do it if it seems like the right thing
Tom Switzer
@tixxit
Feb 10 2015 12:29
given that no other map group operations are lazy, I don’t think we should
It’s possible that it could speed things up, but I think I’d be least surprised if it was strict, like all other methods
I’ll post benchmark results once Isabelle goes down for a nap :)
Tom Switzer
@tixxit
Feb 10 2015 12:59
How would people feel about me moving Spire’s free structures (FreeMonoid, FreeGroup, FreeAbGroup - https://github.com/non/spire/tree/master/core/src/main/scala/spire/algebra/free) over to algebra?
Perhaps in a separate package?
I used them quite a bit in my last job, but if they aren’t useful to others then I’m happy leaving them in Spire too
Tom Switzer
@tixxit
Feb 10 2015 14:34
alright - I added a bunch of benchmarks: https://gist.github.com/tixxit/e80586e62c50bffbdfdb
the take away is that we shouldn’t feel guilty about doing a: (a, b) match { … }
at least from a heap perspective - but that we could do better by avoiding match altogether if we were so inclined to optimize this
Erik Osheim
@non
Feb 10 2015 14:37
ok great
@tixxit thanks! i guess we can do that for now and reconsider based on future profiling
Tom Switzer
@tixxit
Feb 10 2015 14:54
Yeah - I’m glad to see the JVM doing its thing here
:|
Gitter - I just want to post a link, come on
Erik Osheim
@non
Feb 10 2015 14:56
ugh yeah
i'm now looking for a way to turn that off
P. Oscar Boykin
@johnynek
Feb 10 2015 19:32
@tixxit any idea why the difference on TupleHeap vs Tuple version? Seems the compiler should consider that a bug. It is around a factor of 2, right?
Tom Switzer
@tixxit
Feb 10 2015 19:33
@johnynek the TupleHeap let’s the tuple “escape” the method invocation
my thinking is that it would foil the JVM’s escape analysis (because it escapes :))
and thus force the tuple to allocate on the heap and not get optimized to a stack allocation
I think the numbers prove that it the Tuple version is getting stack allocated, which is nice
P. Oscar Boykin
@johnynek
Feb 10 2015 19:53
@tixxit how does it escape? It seems the tuple stays local to the method. Maybe I don't understand how escape analysis works.
Erik Osheim
@non
Feb 10 2015 19:59
tpl = ... assigns to an outer var.
P. Oscar Boykin
@johnynek
Feb 10 2015 20:19
@non what is outer in that example? outer to what? It is all one method call, right?
Tom Switzer
@tixxit
Feb 10 2015 20:22
@johnynek tpl is a var in the class - so after the method returns, the tpl var still lives on
and, specifically, the tuple within it does too
so that tuple is escaping the method
When the tuple is only used locally within the method, the JVM is able to allocate it on the stack, since after the method returns, the tuple can be destroyed
but with TupleHeap we specifically store the tuple outside the method so that the JVM is forced to allocate it on the heap, otherwise the tpl var would contain a bad reference after the method returns
P. Oscar Boykin
@johnynek
Feb 10 2015 20:44
@tixxit ahhh fuck. That was what I was missing. Since only a madman would use a var there, my brain was just inserting val tpl.
Erik Osheim
@non
Feb 10 2015 20:59
hahaha ;)
Tom Switzer
@tixxit
Feb 10 2015 21:19
:)