Skip to content
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

Performance tracker #68

Open
typesanitizer opened this issue Dec 3, 2017 · 3 comments
Open

Performance tracker #68

typesanitizer opened this issue Dec 3, 2017 · 3 comments

Comments

@typesanitizer
Copy link
Contributor

If I understand correctly, the primary motivation behind Sixten's design of having data unboxed by default is cache performance. As documented in the Readme, this approach creates some runtime overhead as functions need to be passed the sizes of the types, as Sixten doesn't do monomorphization by default. It would be nice if we could add some small benchmarks comparing Sixten to other functional languages, to have a concrete sense of how much the net benefit is.

For the monomorphization case, it would be useful to compare to other imperative languages too and check if it is similar where it ought to be. Since this ought to have similar cache performance, we could also isolate the runtime overhead by comparing the monomorphized benchmark with the ordinary benchmark.

An enhancement of this feature would be keeping track of running times over commits automatically. This would be useful when adding and optimizing new features such as records.

@ollef
Copy link
Owner

ollef commented Dec 3, 2017

Agreed, this would be great to have!

@AnthonyJacob
Copy link

AnthonyJacob commented Mar 1, 2018

I would be really interested in this, since if the difference is insignificant, there is probably no reason to use unboxed representation instead of boxed / lazy one.

@ollef
Copy link
Owner

ollef commented Mar 1, 2018

Contributions would be very welcome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants