Ryū: Fast Float-To-String Conversion

Post by qop » Sat, Jul 28, 2018, 11:08 PM UTC

KenoFischer wrote: post #40

qop wrote: post #39

Earlier quoted context omitted.

I really enjoy seeing Julia devs so invested and up-to-date with projects and experiments like this, because isn't this the bread and butter of technical computing? The nitty gritty of making all these bits and bytes do work! So cool. Is Ryu.jl significantly faster than what's in Base? Is there already an open issue somewhere?

Yes, I think preliminary tests showed that it was faster than Grisu (which is what we're using in Base currently). It also seems significantly simpler (Grisu is generally fairly simple but has a custom BigInt implementation to handle some corner cases, which makes things complicated). Not a good time right now to swap the float print algorithm, but a good project for post-1.0. I don't see an issue about it at the mom…

Post by ulfjack » Sun, Jul 29, 2018, 8:52 AM UTC

KenoFischer wrote: post #42

qop wrote: post #41

Earlier quoted context omitted.

To hijack this thread a different direction for a moment, is this type of change one that would be allowed to occur in 1.x? How is it determined what changes are suitable for 1.x and what will wait for 2.0, once 1.0 is released? I'm very interested in how detailed and coordinated the Julia team has become regarding the longer term future of Julia. Admirable effort all around.

I'd say probably yes. Changes are suitable for 1.x if they are not generally breaking for user code. This change probably wouldn't be considered breaking, but we'd have to look at it at the time.

Post by namibj » Wed, Aug 01, 2018, 5:53 AM UTC

cryptonector wrote: post #30

namibj wrote: post #26

Earlier quoted context omitted.

At that point just base-64 for your IEEE floats.... Because anywhere where you need that speed you can better handle it without using strings...

But that's not necessarily interoperable. E.g., some JSON parsers might produce IEEE754 doubles, but others might use arbitrary precision representations -- what then? One answer is to make JSON support only IEEE754 doubles, but it's a bit late for that, so at most one can recommend that implementors stick to IEEE754. If you are starting from scratch, and want to support only platforms that support IEEE754 in hardwar…