You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Numbers (they're called Decimals in Novika) are a vital part of the language. Looping, math, sizing (getting/setting insertion point, obtaining the amount of items in blocks or the amount of characters in a string, etc.) -- all this requires Decimals, and all this requires decimals to be fast.
And they're not.
The Decimal struct can be found in src/novika/forms/decimal.cr. It uses BigDecimal, and BigDecimal only. That's perfectly fine for a prototype, but now is time for optimization. Just remembering BigDecimal is always heap allocated sends shivers down my spine. Some of my benchmarks have shown that big decimal loops are almost 400x times slower than even a badly-designed number promotion engine.
For integers, the goal is to climb the type ladder (promote) with as little overhead as possible. That is, if two (unoptimized) int32 additions happen in X, we should aim at ~2X or less, if being optimistic. Same for all other types: Int64, (maybe) Int128, BigInt. The only expense that can be tolerated is promotion itself. Most of the time, it is not needed at all (e.g., loop counters almost always are int32s and rarely exceed the type's limits). This way, we stay at comfortable speed and 0 memory use, and upon a single promotion, may slow down a bit and use a bit of memory, to then speed up again.
That said, Novika is, and will be a high level, human-oriented language (although one that looks pretty strange). We cannot afford to lose precision. Therefore, floats must always use BigFloat or something like that. In my practice, fast floats are rarely needed (at the moment of writing, Novika doesn't even parse floats; the only way to obtain them is division: `1 2 / ). We'd always be able to implement a similar promotion engine for floats; decimals are much more important and will lead to a much larger, and more easily achievable performance improvement.
If anyone wants to address this, go to the decimal file. The struct is completely isolated. You can yank it out and work with it outside Novika (removing the extends and includes, I guess), and hopefully write tests for it (I really have to make this a habit). Just don't violate the type signatures, and theoretically you'd be able to paste your modified decimal back in and Novika will work fine.
The text was updated successfully, but these errors were encountered:
Numbers (they're called
Decimal
s in Novika) are a vital part of the language. Looping, math, sizing (getting/setting insertion point, obtaining the amount of items in blocks or the amount of characters in a string, etc.) -- all this requiresDecimal
s, and all this requires decimals to be fast.And they're not.
The
Decimal
struct can be found insrc/novika/forms/decimal.cr
. It uses BigDecimal, and BigDecimal only. That's perfectly fine for a prototype, but now is time for optimization. Just remembering BigDecimal is always heap allocated sends shivers down my spine. Some of my benchmarks have shown that big decimal loops are almost 400x times slower than even a badly-designed number promotion engine.For integers, the goal is to climb the type ladder (promote) with as little overhead as possible. That is, if two (unoptimized) int32 additions happen in X, we should aim at ~2X or less, if being optimistic. Same for all other types: Int64, (maybe) Int128, BigInt. The only expense that can be tolerated is promotion itself. Most of the time, it is not needed at all (e.g., loop counters almost always are int32s and rarely exceed the type's limits). This way, we stay at comfortable speed and 0 memory use, and upon a single promotion, may slow down a bit and use a bit of memory, to then speed up again.
That said, Novika is, and will be a high level, human-oriented language (although one that looks pretty strange). We cannot afford to lose precision. Therefore, floats must always use
BigFloat
or something like that. In my practice, fast floats are rarely needed (at the moment of writing, Novika doesn't even parse floats; the only way to obtain them is division: `1 2 / ). We'd always be able to implement a similar promotion engine for floats; decimals are much more important and will lead to a much larger, and more easily achievable performance improvement.If anyone wants to address this, go to the decimal file. The struct is completely isolated. You can yank it out and work with it outside Novika (removing the extends and includes, I guess), and hopefully write tests for it (I really have to make this a habit). Just don't violate the type signatures, and theoretically you'd be able to paste your modified decimal back in and Novika will work fine.
The text was updated successfully, but these errors were encountered: