Faster double parser?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Faster double parser?

Carfield Yim
HI all, just aware of this project,
https://github.com/wrandelshofer/FastDoubleParser, not sure if it good idea
to use this as default Double Parser in JVM?
Reply | Threaded
Open this post in threaded view
|

Re: Faster double parser?

Andrew Haley
On 4/3/21 12:58 PM, Carfield Yim wrote:
> HI all, just aware of this project,
> https://github.com/wrandelshofer/FastDoubleParser, not sure if it good idea
> to use this as default Double Parser in JVM?

We also have a candidate for a String -> toDouble parser from Raffaello
Giulietti:

https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html

As far as I can see there's nothing wrong with it, but it got stuck in
review. This was a bad failure of our review processes, I'm afraid. I
wonder if we will do any better with this one.

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Reply | Threaded
Open this post in threaded view
|

Re: Faster double parser?

Andrew Haley
On 4/4/21 9:53 AM, Andrew Haley wrote:
> On 4/3/21 12:58 PM, Carfield Yim wrote:
>> HI all, just aware of this project,
>> https://github.com/wrandelshofer/FastDoubleParser, not sure if it good idea
>> to use this as default Double Parser in JVM?
>
> We also have a candidate for a String -> toDouble

Argh. Double -> String.

> parser from Raffaello Giulietti:
--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Reply | Threaded
Open this post in threaded view
|

Re: Faster double parser?

Alan Bateman
In reply to this post by Andrew Haley
On 04/04/2021 09:53, Andrew Haley wrote:
> :
> We also have a candidate for a String -> toDouble parser from Raffaello
> Giulietti:
>
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html
>
> As far as I can see there's nothing wrong with it, but it got stuck in
> review. This was a bad failure of our review processes, I'm afraid. I
> wonder if we will do any better with this one.

Yeah, there was a lengthy discussion about this at the OpenJDK Committer
Workshop just after FOSDEM 2020. Brian Burkhalter and Andrew Dinn had
both put time into looking at the proposal it but the conclusion was
that Raffaello's paper "The Schubfach way to render doubles" needed a
review from from an expert in this area. Guy Steele was mentioned but I
don't know if he was approached about it.

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: Faster double parser?

Andrew Haley
On 4/5/21 9:08 AM, Alan Bateman wrote:

> On 04/04/2021 09:53, Andrew Haley wrote:
>> :
>> We also have a candidate for a String -> toDouble parser from Raffaello
>> Giulietti:
>>
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html
>>
>> As far as I can see there's nothing wrong with it, but it got stuck in
>> review. This was a bad failure of our review processes, I'm afraid. I
>> wonder if we will do any better with this one.
>
> Yeah, there was a lengthy discussion about this at the OpenJDK Committer
> Workshop just after FOSDEM 2020. Brian Burkhalter and Andrew Dinn had
> both put time into looking at the proposal it but the conclusion was
> that Raffaello's paper "The Schubfach way to render doubles" needed a
> review from from an expert in this area.

I wonder. The implementation has even been proved correct for floats by
exhaustion. (Of course that's not possible for doubles.)

I submit, therefore, that we could at least use the float version without
reasonable fear of breaking something.

We seem to be paralysed by this one.

> Guy Steele was mentioned but I don't know if he was approached about it.

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Reply | Threaded
Open this post in threaded view
|

Re: Faster double parser?

Brian Burkhalter-2

On Apr 5, 2021, at 4:11 AM, Andrew Haley <[hidden email]<mailto:[hidden email]>> wrote:

On 4/5/21 9:08 AM, Alan Bateman wrote:
On 04/04/2021 09:53, Andrew Haley wrote:
:
We also have a candidate for a String -> toDouble parser from Raffaello
Giulietti:

https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html

As far as I can see there's nothing wrong with it, but it got stuck in
review. This was a bad failure of our review processes, I'm afraid. I
wonder if we will do any better with this one.

Yeah, there was a lengthy discussion about this at the OpenJDK Committer
Workshop just after FOSDEM 2020. Brian Burkhalter and Andrew Dinn had
both put time into looking at the proposal it but the conclusion was
that Raffaello's paper "The Schubfach way to render doubles" needed a
review from from an expert in this area.

I spent some time on it a while back but got bogged down.

I wonder. The implementation has even been proved correct for floats by
exhaustion. (Of course that's not possible for doubles.)

I exhaustively verified it for floats. I also ran round-trip tests for doubles which ran for days without error. Of course one can only disprove by counterexample, not prove by anecdote.

I submit, therefore, that we could at least use the float version without
reasonable fear of breaking something.

That is a good suggestion.

We seem to be paralysed by this one.

Guy Steele was mentioned but I don't know if he was approached about it.

Indirectly.

Another aspect which was raised was supportability: is it sufficiently understood for us to support? On that note I would ask “Is FloatingDecimal sufficiently understood to support?” I think the answer to both questions is the same.

Brian

Reply | Threaded
Open this post in threaded view
|

Re: Faster double parser?

Brian Burkhalter-2
The mailing list mangled formatting. My comments are prefixed below by “->”.

On Apr 5, 2021, at 9:52 AM, Brian Burkhalter <[hidden email]<mailto:[hidden email]>> wrote:

On Apr 5, 2021, at 4:11 AM, Andrew Haley <[hidden email]<mailto:[hidden email]><mailto:[hidden email]>> wrote:

On 4/5/21 9:08 AM, Alan Bateman wrote:
On 04/04/2021 09:53, Andrew Haley wrote:
:
We also have a candidate for a String -> toDouble parser from Raffaello
Giulietti:

https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html

As far as I can see there's nothing wrong with it, but it got stuck in
review. This was a bad failure of our review processes, I'm afraid. I
wonder if we will do any better with this one.

Yeah, there was a lengthy discussion about this at the OpenJDK Committer
Workshop just after FOSDEM 2020. Brian Burkhalter and Andrew Dinn had
both put time into looking at the proposal it but the conclusion was
that Raffaello's paper "The Schubfach way to render doubles" needed a
review from from an expert in this area.

-> I spent some time on it a while back but got bogged down.

I wonder. The implementation has even been proved correct for floats by
exhaustion. (Of course that's not possible for doubles.)

-> I exhaustively verified it for floats. I also ran round-trip tests for doubles which ran for days without error. Of course one can only disprove by counterexample, not prove by anecdote.

I submit, therefore, that we could at least use the float version without
reasonable fear of breaking something.

-> That is a good suggestion.

We seem to be paralysed by this one.

Guy Steele was mentioned but I don't know if he was approached about it.

-> Indirectly.

-> Another aspect which was raised was supportability: is it sufficiently understood for us to support? On that note I would ask “Is FloatingDecimal sufficiently understood to support?” I think the answer to both questions is the same.

Reply | Threaded
Open this post in threaded view
|

Re: Faster double parser?

Brian Burkhalter-2
In reply to this post by Brian Burkhalter-2
The mailing list mangled formatting. My comments are prefixed below by “->”.

On Apr 5, 2021, at 9:52 AM, Brian Burkhalter <[hidden email]<mailto:[hidden email]>> wrote:

On Apr 5, 2021, at 4:11 AM, Andrew Haley <[hidden email]<mailto:[hidden email]><mailto:[hidden email]>> wrote:

On 4/5/21 9:08 AM, Alan Bateman wrote:
On 04/04/2021 09:53, Andrew Haley wrote:
:
We also have a candidate for a String -> toDouble parser from Raffaello
Giulietti:

https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html

As far as I can see there's nothing wrong with it, but it got stuck in
review. This was a bad failure of our review processes, I'm afraid. I
wonder if we will do any better with this one.

Yeah, there was a lengthy discussion about this at the OpenJDK Committer
Workshop just after FOSDEM 2020. Brian Burkhalter and Andrew Dinn had
both put time into looking at the proposal it but the conclusion was
that Raffaello's paper "The Schubfach way to render doubles" needed a
review from from an expert in this area.

-> I spent some time on it a while back but got bogged down.

I wonder. The implementation has even been proved correct for floats by
exhaustion. (Of course that's not possible for doubles.)

-> I exhaustively verified it for floats. I also ran round-trip tests for doubles which ran for days without error. Of course one can only disprove by counterexample, not prove by anecdote.

I submit, therefore, that we could at least use the float version without
reasonable fear of breaking something.

-> That is a good suggestion.

We seem to be paralysed by this one.

Guy Steele was mentioned but I don't know if he was approached about it.

-> Indirectly.

-> Another aspect which was raised was supportability: is it sufficiently understood for us to support? On that note I would ask “Is FloatingDecimal sufficiently understood to support?” I think the answer to both questions is the same.

Reply | Threaded
Open this post in threaded view
|

Re: Faster double parser?

Raffaello Giulietti
In reply to this post by Carfield Yim
Hi,

if there's revived interest I would be glad to migrate the code to
Skara/GitHub for a PR. The last uploaded version is still on Mercurial,
I assume, under Brian Burkhalter's webrev folder.

But I'd also like to point out that there is a pending CSR as well.

(Sorry for the initiator of this thread: you're speaking about a parser,
we about the opposite.)


Greetings
Raffaello



> The mailing list mangled formatting. My comments are prefixed below by “->”.
>
> On Apr 5, 2021, at 9:52 AM, Brian Burkhalter <brian.burkhalter at oracle.com<mailto:brian.burkhalter at oracle.com>> wrote:
>
> On Apr 5, 2021, at 4:11 AM, Andrew Haley <aph at redhat.com<mailto:aph at redhat.com><mailto:aph at redhat.com>> wrote:
>
> On 4/5/21 9:08 AM, Alan Bateman wrote:
> On 04/04/2021 09:53, Andrew Haley wrote:
> :
> We also have a candidate for a String -> toDouble parser from Raffaello
> Giulietti:
>
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html
>
> As far as I can see there's nothing wrong with it, but it got stuck in
> review. This was a bad failure of our review processes, I'm afraid. I
> wonder if we will do any better with this one.
>
> Yeah, there was a lengthy discussion about this at the OpenJDK Committer
> Workshop just after FOSDEM 2020. Brian Burkhalter and Andrew Dinn had
> both put time into looking at the proposal it but the conclusion was
> that Raffaello's paper "The Schubfach way to render doubles" needed a
> review from from an expert in this area.
>
> -> I spent some time on it a while back but got bogged down.
>
> I wonder. The implementation has even been proved correct for floats by
> exhaustion. (Of course that's not possible for doubles.)
>
> -> I exhaustively verified it for floats. I also ran round-trip tests for doubles which ran for days without error. Of course one can only disprove by counterexample, not prove by anecdote.
>
> I submit, therefore, that we could at least use the float version without
> reasonable fear of breaking something.
>
> -> That is a good suggestion.
>
> We seem to be paralysed by this one.
>
> Guy Steele was mentioned but I don't know if he was approached about it.
>
> -> Indirectly.
>
> -> Another aspect which was raised was supportability: is it sufficiently understood for us to support? On that note I would ask “Is FloatingDecimal sufficiently understood to support?” I think the answer to both questions is the same.

Reply | Threaded
Open this post in threaded view
|

Re: Faster double parser?

Brian Burkhalter-2

On Apr 6, 2021, at 3:40 PM, Raffaello Giulietti <[hidden email]<mailto:[hidden email]>> wrote:

if there's revived interest I would be glad to migrate the code to Skara/GitHub for a PR. The last uploaded version is still on Mercurial, I assume, under Brian Burkhalter's webrev folder.

Is the Hg version current?

http://cr.openjdk.java.net/~bpb/4511638/webrev.04/

Converting the patch to Git is straightforward.

But I'd also like to point out that there is a pending CSR as well.

https://bugs.openjdk.java.net/browse/JDK-8202555

Thanks,

Brian
Reply | Threaded
Open this post in threaded view
|

Re: Faster double parser?

Raffaello Giulietti
Hi,

yes, the code in itself is current.

I would need to adapt it to OpenJDK coding conventions; in particular
the form of multiline comments is not the usual one. Only cosmetic
changes, though. Nothing would affect the executable code.

Also, the current patch modifies some existing files, so I need to check
that nothing has changed in the meantime.

I'll prepare a PR in the next couple of days.




On 2021-04-07 00:44, Brian Burkhalter wrote:

>
>> On Apr 6, 2021, at 3:40 PM, Raffaello Giulietti
>> <[hidden email] <mailto:[hidden email]>>
>> wrote:
>>
>> if there's revived interest I would be glad to migrate the code to
>> Skara/GitHub for a PR. The last uploaded version is still on
>> Mercurial, I assume, under Brian Burkhalter's webrev folder.
>
> Is the Hg version current?
>
> http://cr.openjdk.java.net/~bpb/4511638/webrev.04/ 
> <http://cr.openjdk.java.net/~bpb/4511638/webrev.04/>
>
> Converting the patch to Git is straightforward.
>
>> But I'd also like to point out that there is a pending CSR as well.
>
> https://bugs.openjdk.java.net/browse/JDK-8202555 
> <https://bugs.openjdk.java.net/browse/JDK-8202555>
>
> Thanks,
>
> Brian