On Saturday, 25 May 2019 at 07:26:47 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 24 May 2019 at 23:55:13 UTC, Jonathan Marler wrote:
>> Ulf's algorithm can be implemented in only a few hundred lines and apparently is the fastest implementation to-date that maintains a 100% robust algorithm.

>
> It is quite interesting that you get that performance without bloat.

L1 instruction cache are small and the cost of code bloat is only rarely counted. Benchmarks are overwhelmingly good mannered concerning instruction caches.
This makes that optimisation for instruction cache are neglected.

I had once on our project a heavily optimised function with a lot of subcases, loop unrolling etc. In the test benchmark it was the fastest to all alternatives. When using in the final application, the simple 2 line loop in pure C, outrun it in the concrete application. With valgrind cachegrind I discovered that the misses in instruction cache made a big, big, difference.

>
> I wonder if it is faster than the special cased float implementations. (using an estimator that chooses a faster floating point version where it works).
>
>> But's it's very new, only a year old I think.  Cool innovation.
>
>

On Saturday, 25 May 2019 at 11:27:43 UTC, Patrick Schluter wrote:
> L1 instruction cache are small and the cost of code bloat is only rarely counted. Benchmarks are overwhelmingly good mannered concerning instruction caches.

Yes, in benchmarking one should only test full applications… I guess invalidating the cache every N iterations is a possibility in a synthetic benchmark.

> This makes that optimisation for instruction cache are neglected.

Right, I'm interested in seeing what Mike Franklin does for embedded. A minimalistic framework would be interesting to see.

> concrete application. With valgrind cachegrind I discovered that the misses in instruction cache made a big, big, difference.

Interesting, I really need to try that cachegrind some time. Sounds very useful.

On 5/24/19 7:58 PM, Mike Franklin wrote:
> On Friday, 24 May 2019 at 22:59:10 UTC, Walter Bright wrote:
> 
>> C's printf has been hammered on by literally generations of programmers over 3 decades. While the interface to it is old-fashioned and unsafe, the guts of it are rock solid, fast, and correct.
> 
> That may be true, but one problem with `printf` is it is much too large and inefficient for some problem domains [1].
> 
> Rust has a more efficient `printf` alternative which is not dependent on a runtime or libc [2].
> 
> D could offer a *much* more efficient, pay-for-what-you-use implementation that doesn't require libc, a runtime, etc., like Rust's implementation.  It wouldn't be easy (especially wrt floating point types), but it would be a great benefit to D and its users.  Maybe I'll add it to dlang/projects [3].
> 
> There seems to be a perception about C that because it's old and proven, it's magical.  There's nothing `printf` is doing that D can't do better, if someone would just be willing to do the hard work.

The high impact part is the metaprogramming and introspection machinery. This is where D can contribute something innovative to the larger programming community. Yet another implementation of formatting primitives is low impact.

On Saturday, 25 May 2019 at 14:40:09 UTC, Andrei Alexandrescu wrote:
> The high impact part is the metaprogramming and introspection machinery. This is where D can contribute something innovative to the larger programming community. Yet another implementation of formatting primitives is low impact.

Programmers are looking for solutions, not machinery…

Many people might want to use D for Arduino if it was a plug&play.

On Saturday, 25 May 2019 at 14:40:09 UTC, Andrei Alexandrescu wrote:
> The high impact part is the metaprogramming and introspection machinery. This is where D can contribute something innovative to the larger programming community.

I'd think you'd be commenting on the "Issue 5710" thread then, as that very much does affect the metaprogramming capabilities of D. I do agree that this is an area where D shines and where D can show off the most compared to its competitors.

> Yet another implementation of formatting primitives is low impact.

You're probably right, but the people implementing this in D are already doing or have done it, so that's a good thing. Also, as someone who will likely only use the betterC subset of D, having some better primitives than printf in BetterC is a small boon, though I'd rather have something more like the new C++ fmt library than like printf.

On 5/25/2019 1:42 AM, Joseph Rushton Wakeling wrote:
> FWIW the Ryu algorithm looks like a serious piece of work — see this paper, which references (and compares in detail) to the paper you linked to:
> https://dl.acm.org/citation.cfm?id=3192369
> 
> It covers in some detail the rationale for the differences you note.

Thank you. I've saved a copy of the paper. It it is indeed

1. faster
2. more accurate
3. supports all the options (precision, etc.) with %e %f %g

then it is indeed a candidate for inclusion in Phobos' std.format. But not for this exercise.

>> Floating point formatting is not something that can be knocked out in an hour. You can get a "mostly working" implementation that way, but not a serious, robust, correct implementation with the expected flexibility. (And the test cases to prove it correct.)
> 
> One interesting remark in the paper on the Ryu algorithm: "We did not compare our implementation against the C standard library function printf, as its specification does not include the correctness criteria set forth by Steele and White [15], and, accordingly, neither the glibc nor the MacOS implementation does."

The C standard library does indeed not have correctness criteria for floating point formatting nor for the trig functions, and that does lead to some sloppy implementations, but the mainstream compilers do it well and are expected to.

I once attended a presentation on numerics by a math professor, who said the C trig functions on FreeBSD were extremely reliable. He was rather upset (and didn't believe me) when I said I'd tested them and found errors in the last digit.

It should be a point of pride for the D language to have the floating point "good to the last bit" and I'm always interested in contributions that get us there.