Skip to content

Optimize the storage backend used in sketch map #301

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 15, 2014
Merged

Conversation

ianoc
Copy link
Collaborator

@ianoc ianoc commented Apr 14, 2014

Seeing somewhere between 1.7x and 5x perf improvements depending on loaded ness of the sketchmap.


// The adaptive monoid to swap between sparse modes.
implicit def monoid[V:Monoid]: Monoid[AdaptiveMatrix[V]] = new Monoid[AdaptiveMatrix[V]] {
private[this] final val innerZero = implicitly[Monoid[V]].zero
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a reason you generally prefer the implicitly[Monoid... approach vs. Monoid.zero[V], and so on?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly not really, this ensures its just a field access for the zero constant in here if we hit it often rather than potentially being a def/virtual call

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How smart is implicitly? I always thought it was just something like

def implicitly[T](implicit t: T) = t

Which would mean that there is still a virtual call. Is the scala compiler actually doing something smarter here, like making a direct reference to the implicit type that is in scope?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, but i assign it to a final val, that is then used in any loops/accesses within the monoid. So for those it should be a constant. I could have used Monoid.zero[T] in the constant here too. Sorry I think I might have answered a different question than asked. both put into this line I presume both are just equiv

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, yeah, I think we diverged, but I am with you.

case d@DenseMatrix(_, _, _) => return denseUpdate(d, iter)
case s@SparseColumnMatrix(_) =>
sparseUpdate(sparseStorage, s)
if(sparseStorage(0).size > current.cols/4) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps this logic should be in a method/constant whatever?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well this is the only place it exists in the code I modified, now if we should have some notion for all our sparse/adaptive systems for when to go dense, maybe. Also maybe should be a parameter. Not sure really.

jcoveney added a commit that referenced this pull request Apr 15, 2014
Optimize the storage backend used in sketch map
@jcoveney jcoveney merged commit 48fd31b into develop Apr 15, 2014
@jcoveney jcoveney deleted the sketchmap_opti branch April 15, 2014 22:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants