Post B4F1OKvzn9bMo4cGSe by skewray@mathstodon.xyz
(DIR) More posts by skewray@mathstodon.xyz
(DIR) Post #B4F1OJjCHFln45cWsC by skewray@mathstodon.xyz
0 likes, 0 repeats
According to Wikipedia, the only modern processor with 128-bit IEEE floating point is the IBM POWER9. Out of curiosity, using my Intel desktop I did a floating point speed test in C (gcc no optimization) with a zillion [multiply and 2 adds] operations. These are the results, normalized to float:1 float1 double85 long double7.3 quad (__float128)Um. Looks like this processor has hardware quad and emulates 80287 10-byte long double in software?I am shocked. Shocked! Processor is 13th Gen Intel® Core™ i9-13900 (24-Core, 32MB Cache, 2.0 GHz).
(DIR) Post #B4F1OJxjPDObnAQ8Wm by skewray@mathstodon.xyz
0 likes, 0 repeats
So, apparently this is what happens when the value overflows and the processor is dealing with 'inf' in the loop: long double is much slower with exceptions. With numbers and not exceptions, the results are (now multiply and single add):gcc -O0float 1.00double 1.00long 1.32quad 8.5125.605u 0.000s 0:25.60 100.0% 0+0k 0+0io 0pf+0wgcc -O1float 1.00double 0.90 long 1.23 quad 8.4925.521u 0.001s 0:25.52 100.0% 0+0k 0+8io 0pf+0wgcc -O2float 1.00 double 0.99 long 1.36 quad 8.75 24.135u 0.000s 0:24.13 100.0% 0+0k 0+0io 0pf+0wgcc -O3float 1.00double 1.00 long 1.38quad 8.8324.144u 0.000s 0:24.14 100.0% 0+0k 0+8io 0pf+0wOptimization makes little to no difference to speed, as expected.
(DIR) Post #B4F1OKEkNx0UdwNj3A by skewray@mathstodon.xyz
0 likes, 0 repeats
Seems to be a compiler issue, and only long double when unoptimized.TYPE NUM NAN INFfloat 1.00 0.99 0.99double 0.99 0.99 0.99long 1.25 69.68 72.13quad 8.42 5.99 6.61369.205u 0.000s 6:09.22 99.9%0+0k 0+8io 0pf+0wgcc -O1float 1.00 0.14 0.14double 1.00 0.14 0.14long 1.00 0.14 0.14quad 13.96 0.15 0.1522.730u 0.000s 0:22.73 100.0%0+0k 0+0io 0pf+0wgcc -O2float 1.00 0.00 0.00double 0.98 0.00 0.00long 0.99 0.00 0.00quad 13.67 0.00 0.0021.258u 0.000s 0:21.25 100.0%0+0k 0+8io 0pf+0wgcc -O3float 1.00 0.00 0.00double 0.98 0.00 0.00long 0.98 0.00 0.00quad 13.53 0.00 0.0021.094u 0.000s 0:21.09 100.0%0+0k 0+0io 0pf+0w
(DIR) Post #B4F1OKULRxU3QJgBMW by skewray@mathstodon.xyz
0 likes, 0 repeats
@AmenZwa @dougmerritt https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124434
(DIR) Post #B4F1OKjwVxxcCgydfs by AmenZwa@mathstodon.xyz
0 likes, 0 repeats
@skewray @dougmerritt Holy Smoke!
(DIR) Post #B4F1OKvzn9bMo4cGSe by skewray@mathstodon.xyz
0 likes, 0 repeats
@AmenZwa @dougmerritt The bug report already got rejected. Turns out that x87 emulation is nasty. There's a big discussion in the bug ticket.
(DIR) Post #B4F1OLAAwQwbW3FaYy by dougmerritt@mathstodon.xyz
0 likes, 0 repeats
@skewray @AmenZwa "Rejected" seems extreme of them.
(DIR) Post #B4F1OLLAHZjc48OMgy by skewray@mathstodon.xyz
0 likes, 0 repeats
@dougmerritt @AmenZwa I'm not sure if gcc can fix it. If the x87 variables are loaded on the stack for debugging, (which is supposedly what the default of -O0 means), then unwinding the stack on fault is slow. At least, that's the story they are telling, and they've marked it 'invalid' rather than 'wontfix'. I bet gcc never marks anything 'wontfix'.The fundamental issue is that the x87 architecture belongs in a museum.
(DIR) Post #B4F1OLWVbOoCdJhQNE by dougmerritt@mathstodon.xyz
0 likes, 0 repeats
@skewray @AmenZwa Yeah, at worst I expected "wontfix", so -- good points> The fundamental issue is that the x87 architecture belongs in a museum.No argument there. Getting past all the obvious counter-arguments, we arrive at Arm, but billion devices or not, it's proprietary, which brings us to RISC-V, which I don't follow closely, but people seem to keep saying that it's not ready for various reasons.I dunno. Life sucks and then you die.P.S.> the only modern processor with 128-bit IEEE floating point is the IBM POWER9I suppose I'm a little surprised by that.
(DIR) Post #B4F1OLoaWBGpXO9rYO by skewray@mathstodon.xyz
0 likes, 0 repeats
@dougmerritt @AmenZwa Yesterday I went for a walk through eBay offerings on POWER9. It would be pretty easy to put together a POWER9 (or maybe even Power10) computer, probably for about US$5K+. (Maybe if I win the lottery?) Otherwise, quad is about 7 times slower than long double, so if I need speed, I can just run code on all 32 Intel processors and I am still ahead.For the computations I was doing late last year, long double wasn't good enough anyway; I needed quad accuracy.("x87" refers to the x86 floating point co-processor, which used 80-bit floating point. Long double is 10 bytes long and stored in a 16-byte space with 4 zeroed-out bytes. Super-retro.)
(DIR) Post #B4F1OM99HjiWZ9mHbM by dougmerritt@mathstodon.xyz
0 likes, 0 repeats
@skewray @AmenZwa > "x87" refers to the x86 floating point co-processor, which used 80-bit floating point.Yes.> Long double is 10 bytes long and stored in a 16-byte space with 4 zeroed-out bytes.*That* I did not know. I guess I've never actually laid hands on it. (Edit: of course I've used 80 bit, I meant I've never noticed those memory layout details)But you know, the GNU multiprecision libraries are optimized to hell and gone, beyond the ability of mere mortals to add further optimization. You might get the speed you want just from that.
(DIR) Post #B4F1OMQWF9bzR1u9g0 by ChuckMcManis@chaos.social
1 likes, 0 repeats
@dougmerritt @skewray @AmenZwa This has been such an interesting thread. Here's another funny story, Guy Steele came work with us at "First Person" (the Project Green group at Sun that wrote Java). So we had Guy Steele (TECO version of EMACS), James Gosling (gosling EMACS), and Jon Payne (JOVE, Jonathans Own Version of EMACS) all in the same group. I still used vi though 😃
(DIR) Post #B4F1WGHEzXL6g9KfFA by dougmerritt@mathstodon.xyz
0 likes, 0 repeats
@ChuckMcManis @skewray @AmenZwa Huh!At several removes I knew they were there (because I'm a busybody I suppose), but I certainly never thought of the emacs connection.And I only know of JOVE from history books! Very memorable acronym. Like the similarly-named JOVIAL (Jule's Own Version of the International Algorithmic Language).
(DIR) Post #B4F1WGU0E5Y1JjIr8S by ChuckMcManis@chaos.social
1 likes, 0 repeats
@dougmerritt @skewray @AmenZwa And my favorite was Craig Finseth's whose MIT thesis in May 1980 was "Theory and Practice of Text Editors, or A Cookbook For An EMACS", His program (which ran on TOPS-10) was named "FINE" which stood for "FINE Is Not EMACS" 😃. I've still got my copy!