Re: std.math performance (SSE vs. real)
On Friday, 4 July 2014 at 17:05:16 UTC, Walter Bright wrote: On 7/4/2014 3:38 AM, Don wrote: What is the longest type supported by the native hardware? I don't know what that means, and I don't think it even makes sense. Most of the time, it is quite clear. For example, Sparc has 128-bit quads, but they only have partial support. Effectively. they are emulated. Why on earth would you want to use an emulated type on some machines, but not on others? Emulation is not native support. I think the only difference it makes is performance. But there is not very much difference in performance between double-double, and implementations using microcode. Eg PowerPC double-doubles operations require fewer clock cycles than x87 operations on 286. Perhaps the intention was the largest precision you can get for free, without sacrificing speed then that's not clearly defined. On x86-32, that was indeed 80 bits. But on other systems it doesn't have an obvious answer. On x86-64 it's not that simple. Nor on PPC or Sparc. Yes, there is some degree of subjectivity on some platforms. I don't see a good reason for hamstringing the compiler dev with legalese for Platform X with legalese that isn't quite the right thing to do for X. I agree. But I think we can achieve the same outcome while providing more semantic guarantees to the programmer. I think the intention of the spec is clear, and the compiler implementor can be relied on to exercise good judgement. The problem is that the developer cannot write code without knowing the semantics. For example, one of the original motivations for having 80-bit floats on the x87 was that for many functions, they give you correctly-rounded results for 'double' precision. If you don't have 80-bit reals, then you need to use far more complicated algorithms. If your code needs to work on a system with only 64 bit reals, then you have to do the hard work. Something I've come to realize, was that William Kahan's work was done in a world before generic programming. He had constraints that we don't have. Our metaprogramming system gives us great tools to get the highest accuracy and performance out of any processor. We can easily cope with the messy reality of real-world systems, we don't need to follow Java in pretending they are all the same. This is something we're good at! A 'real' type that has system-dependent semantics is a poor-man's generics. Take a look at std.math, and see all the instances of 'static if (real.mant_dig == '. Pretty clearly, 'real' is acting as if it were a template parameter. And my experience is that any code which doesn't treat 'real' as a template parameter, is probably incorrect. I think we should acknowledge this.
Re: std.math performance (SSE vs. real)
Ola Fosheim Grøstad: Both Delight and FeepingCreature appears to be alive. I guess that is a good sign. I still like the idea of having in D something like the F# language directive #light that switches to a brace-less syntax: http://msdn.microsoft.com/en-us/library/dd233199.aspx I think at first the verbose syntax was the standard one in F#, but later the light one has become the standard one. Bye, bearophile
Re: std.math performance (SSE vs. real)
On Sunday, 6 July 2014 at 17:19:24 UTC, bearophile wrote: I still like the idea of having in D something like the F# language directive #light that switches to a brace-less syntax: I like compact syntax, like the reduction in clutter done with Go. I've been thinking a lot about how to improve the assignments in C-like languages. Seems to me that when it comes to immutable values it makes sense to deal with them in a functional style. I.e. there is no real need to distinguish between a comparison of equality and a defined equality (assignment). Of course, that means boolean contexts have to be made explicit to avoid ambiguity. IMO reducing clutter becomes really important when you use the language for describing content that needs to be modified and extended.
Re: std.math performance (SSE vs. real)
On Fri, 2014-07-04 at 12:48 +, via Digitalmars-d wrote: […] I pick the most stable tool for the job. Meaning I usually end up with C, conservative use of C++, Python 2.7, Javascript, SQL or […] That should, of course, have read Python 3.4! -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: std.math performance (SSE vs. real)
On Saturday, 5 July 2014 at 06:48:23 UTC, Russel Winder via Digitalmars-d wrote: That should, of course, have read Python 3.4! Most of my code has to run on App Engine, so I stick to whatever version Google use for all my Python stuff. They had Guido do their db-api a couple of years back so they probably stick with 2.7 for a good reason? Sometimes stable means with known bugs and known work-arounds. ;)
Re: std.math performance (SSE vs. real)
On Friday, 4 July 2014 at 21:49:33 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 July 2014 at 21:08:27 UTC, Walter Bright wrote: Sadly, this also implies that there are no computer languages you believe in. You set an impossible standard. How can you possibly say you prefer C++, a classic design by committee language? I don't prefer it. I think it sucks, but it is the only viable choice if you want to create a scalable game or virtual world server. Again, outside, in the real business world, reality is a little different: take this monster, look, no C++! http://www.robg3d.com/2014/01/why-ccp-is-still-using-python-2/ http://www.pcgamer.com/2013/06/15/eve-online/ What I loved about D, from the real beginning, was this: pragmatism, pragmatism! And after the love, what moved us as a company to adopt it was Walter: He is a deeply pragmatic guy! Pragmatism is an invaluable asset in business (btw, THAT should be stressed in the logo/identity/redesign looong thread) --- Paolo
Re: std.math performance (SSE vs. real)
On Saturday, 5 July 2014 at 09:39:10 UTC, Paolo Invernizzi wrote: Again, outside, in the real business world, reality is a little different: take this monster, look, no C++! http://www.robg3d.com/2014/01/why-ccp-is-still-using-python-2/ http://www.pcgamer.com/2013/06/15/eve-online/ I don't play Eve, but in general the challenge in virtual worlds is that you need to do full veracity checking on the server to reduce cheating. You should also hide parts of the model so that only the server knows it. Basically, you have to run the entire sim on the server and only run parts of it on the client for display purposes if you want to reduce cheating without introducing draconian measures that basically takes over the machine (which cannot work if the client runs in the browser). Anyway, at the end of the day, for a freemium game you need to cut server costs because you cannot estimate correctly how much money you make per online user. With a subscription model you are better off and can spend more on hardware. What you can or cannot do, depends on the business model, the market and the game design… What I loved about D, from the real beginning, was this: pragmatism, pragmatism! I am pragmatic about this. I have stuff planned that can run on Python on top of Google Datastore on the server and use Dart+WebGL on the client. But if you want a physics based model, user building and fast travelling you have to consider the worst case scenario and you cannot do it in Python or using a disk based database. You need a in-memory database and hit the hardware so that you can take the peaks without ending up with molasses of latency. And after the love, what moved us as a company to adopt it was Walter: He is a deeply pragmatic guy! Pragmatism is an invaluable asset in business (btw, THAT should be stressed in the logo/identity/redesign looong thread) The most valuable factor in business is predictability, opportunities and being better at cutting costs than the competition. Google are pragmatic, they dump IE9 on most of their platforms. Unfortunately for businesses using Google tech that means loss of predictability, lost opportunities and increased costs. Pragmatism in the context of D is community building. Sure, being pragmatic about the logo is important, you should encourage people using it in different ways because it is a community building tool (among many). Like the penguin in Linux being used in games etc. Community building means encouraging participation and setting direction. If you don't set direction, people will sit on the fence waiting for something to happen. Communities don't build skeletons, they add meat to the bones.
Re: std.math performance (SSE vs. real)
On Saturday, 5 July 2014 at 11:14:40 UTC, Ola Fosheim Grøstad wrote: On Saturday, 5 July 2014 at 09:39:10 UTC, Paolo Invernizzi wrote: Again, outside, in the real business world, reality is a little different: take this monster, look, no C++! http://www.robg3d.com/2014/01/why-ccp-is-still-using-python-2/ http://www.pcgamer.com/2013/06/15/eve-online/ I don't play Eve, but in general the challenge in virtual worlds is that you need to do full veracity checking on the server to reduce cheating. You should also hide parts of the model so that only the server knows it. Basically, you have to run the entire sim on the server and only run parts of it on the client for display purposes if you want to reduce cheating without introducing draconian measures that basically takes over the machine (which cannot work if the client runs in the browser). Anyway, at the end of the day, for a freemium game you need to cut server costs because you cannot estimate correctly how much money you make per online user. With a subscription model you are better off and can spend more on hardware. What you can or cannot do, depends on the business model, the market and the game design… I agree, but keep this is mind: a business model is not carved in stone, it keeps changing, as the market is not a static thing. And this is true also in the programming language field, as the IT universe is not a static thing. I liked the Lang.NEXT panel, especially when Bjarne talked about the real world pressure over C++... What I loved about D, from the real beginning, was this: pragmatism, pragmatism! I am pragmatic about this. I have stuff planned that can run on Python on top of Google Datastore on the server and use Dart+WebGL on the client. But if you want a physics based model, user building and fast travelling you have to consider the worst case scenario and you cannot do it in Python or using a disk based database. You need a in-memory database and hit the hardware so that you can take the peaks without ending up with molasses of latency. If you read carefully, EVE was not designed for the actual number of concurrent users: they was forced to keep changing, to survive the challenges. The worst case scenario is the today worst case scenario. You can't design now for what you think will be the needs in a too much distance future, that's will put your product in the Longhorn cemetery. Things need to be done now, to get the current business opportunity window. And after the love, what moved us as a company to adopt it was Walter: He is a deeply pragmatic guy! Pragmatism is an invaluable asset in business (btw, THAT should be stressed in the logo/identity/redesign looong thread) The most valuable factor in business is predictability, opportunities and being better at cutting costs than the competition. Thinks are a little more complicated than that, but well, at the end, business is all about satisfying the needs of someone else who is free to choose among alternatives. So, turning back into the floating point issue of the thread, what's the most pragmatic move D can take about that floating point performance issue? Take the road that satisfy better the most demanded need asked nowadays by D user base, so speed by default. Satisfy the precision demand with real, but keep this need in an explicit language domain corner: there's no silver bullet. Pragmatism in the context of D is community building. Sure, being pragmatic about the logo is important, you should encourage people using it in different ways because it is a community building tool (among many). Like the penguin in Linux being used in games etc. Community building means encouraging participation and setting direction. If you don't set direction, people will sit on the fence waiting for something to happen. Communities don't build skeletons, they add meat to the bones. What I was meaning: a pragmatic language is a beautiful business claim, let's stress it: it worked very well for me! --- Paolo
Re: std.math performance (SSE vs. real)
On Saturday, 5 July 2014 at 13:16:28 UTC, Paolo Invernizzi wrote: I agree, but keep this is mind: a business model is not carved in stone, it keeps changing, as the market is not a static thing. Ok, but for the virtual world side I am more driven by (artistic) model needs than the business side. So I am looking for a solution that fits the requirements. And this is true also in the programming language field, as the IT universe is not a static thing. No, but for contractual work I need to be able to add small enhancements 12 months after deployment without adding transition costs. So a static dev environment matters a lot. If a customer expect that an enhancement takes 10 hours to add, I cannot charge for 50 hours. So if the dev environment incurs a transition cost I have to accept the enhancement request at a loss. (App Engine is pretty stable and has a 12 months guarantee, which is on the low side IMO. I think 24 months would be more appropriate.). If you read carefully, EVE was not designed for the actual number of concurrent users: I only glossed over it. I read external analyses of EVE 10 years ago when I studied online worlds. I believe they had some significant performance problems back. But the game model is not really low latency based. You can't design now for what you think will be the needs in a too much distance future, that's will put your product in the Longhorn cemetery. Things need to be done now, to get the current business opportunity window. I'm not interested in virtual worlds for the business, but for the art of it. So my basic ideas are 10-20 years old and basically just waiting for the technology to catch up. ;^) If I have to nudge the tech to make the last mile, ok, then I might have to do so… So, turning back into the floating point issue of the thread, what's the most pragmatic move D can take about that floating point performance issue? Provide the tools to specify the constraints, like you do for nogc/safe, but with version support. But I think D should be specified, not by the implementation, but in a paper. And I think the language should be cleaned up a bit, on paper, without thinking about the implementation cost for a specific compiler. Because if the resulting language is a true beauty, then more hands will come to add meat to the bones. I'm not complaining about requiring strict IEEE 754 compliance, I am complaining about requiring it and then saying that it does not matter what the compiler devs do. Because it is obvious that on many platforms you don't get full compliance for special cases without some kind of software emulation/handling. What I was meaning: a pragmatic language is a beautiful business claim, let's stress it: it worked very well for me! Python is a very pragmatic language, I don't like the dynamic aspects, but it is one of the most pragmatic languages out there. The way I see it now, the most pragmatic solution would be to fork D, clean up the syntax a bit and make it work well for the domain of game servers. I don't need the libraries. Only UDP/TCP. Whether that is cost efficient compared to just using C++, I dunno. But the more I follow the discussions on the D forums, the more I feel that forking will be more productive than spending effort on affecting the current direction (which most probably will not get me what I want).
Re: std.math performance (SSE vs. real)
On 5 July 2014 15:20, via Digitalmars-d digitalmars-d@puremagic.com wrote: On Saturday, 5 July 2014 at 13:16:28 UTC, Paolo Invernizzi wrote: I agree, but keep this is mind: a business model is not carved in stone, it keeps changing, as the market is not a static thing. Ok, but for the virtual world side I am more driven by (artistic) model needs than the business side. So I am looking for a solution that fits the requirements. And this is true also in the programming language field, as the IT universe is not a static thing. No, but for contractual work I need to be able to add small enhancements 12 months after deployment without adding transition costs. So a static dev environment matters a lot. If a customer expect that an enhancement takes 10 hours to add, I cannot charge for 50 hours. So if the dev environment incurs a transition cost I have to accept the enhancement request at a loss. (App Engine is pretty stable and has a 12 months guarantee, which is on the low side IMO. I think 24 months would be more appropriate.). If you read carefully, EVE was not designed for the actual number of concurrent users: I only glossed over it. I read external analyses of EVE 10 years ago when I studied online worlds. I believe they had some significant performance problems back. But the game model is not really low latency based. You can't design now for what you think will be the needs in a too much distance future, that's will put your product in the Longhorn cemetery. Things need to be done now, to get the current business opportunity window. I'm not interested in virtual worlds for the business, but for the art of it. So my basic ideas are 10-20 years old and basically just waiting for the technology to catch up. ;^) If I have to nudge the tech to make the last mile, ok, then I might have to do so… So, turning back into the floating point issue of the thread, what's the most pragmatic move D can take about that floating point performance issue? Provide the tools to specify the constraints, like you do for nogc/safe, but with version support. But I think D should be specified, not by the implementation, but in a paper. And I think the language should be cleaned up a bit, on paper, without thinking about the implementation cost for a specific compiler. Because if the resulting language is a true beauty, then more hands will come to add meat to the bones. I'm not complaining about requiring strict IEEE 754 compliance, I am complaining about requiring it and then saying that it does not matter what the compiler devs do. Because it is obvious that on many platforms you don't get full compliance for special cases without some kind of software emulation/handling. This is a library problem, not a language problem. In this case std.math uses real everywhere when perhaps it shouldn't. What I was meaning: a pragmatic language is a beautiful business claim, let's stress it: it worked very well for me! Python is a very pragmatic language, I don't like the dynamic aspects, but it is one of the most pragmatic languages out there. http://pyd.dsource.org The way I see it now, the most pragmatic solution would be to fork D, clean up the syntax a bit and make it work well for the domain of game servers. I don't need the libraries. Only UDP/TCP. Whether that is cost efficient compared to just using C++, I dunno. But the more I follow the discussions on the D forums, the more I feel that forking will be more productive than spending effort on affecting the current direction (which most probably will not get me what I want). You mean, MiniD? Someone has already done that, years ago http://jfbillingsley.com/croc/wiki/Lang/GettingStarted
Re: std.math performance (SSE vs. real)
On Saturday, 5 July 2014 at 15:09:28 UTC, Iain Buclaw via Digitalmars-d wrote: This is a library problem, not a language problem. In this case std.math uses real everywhere when perhaps it shouldn't. If x/y leads to a division by zero trap when it should not, then it isn't a library problem. You mean, MiniD? Someone has already done that, years ago No, I meant forking D.
Re: std.math performance (SSE vs. real)
Ola Fosheim Grøstad: No, I meant forking D. There is already Delight and FeepingCreature has created a D-like language. If you fork D you will have lot of fun :-) Keep us updated. Bye, bearophile
Re: std.math performance (SSE vs. real)
On Saturday, 5 July 2014 at 15:28:00 UTC, bearophile wrote: There is already Delight and FeepingCreature has created a D-like language. If you fork D you will have lot of fun :-) Thanks :) Both Delight and FeepingCreature appears to be alive. I guess that is a good sign.
Re: std.math performance (SSE vs. real)
On 5 July 2014 16:13, via Digitalmars-d digitalmars-d@puremagic.com wrote: On Saturday, 5 July 2014 at 15:09:28 UTC, Iain Buclaw via Digitalmars-d wrote: This is a library problem, not a language problem. In this case std.math uses real everywhere when perhaps it shouldn't. If x/y leads to a division by zero trap when it should not, then it isn't a library problem. Right, it's a quirk of the CPU.
Re: std.math performance (SSE vs. real)
On Saturday, 5 July 2014 at 16:24:28 UTC, Iain Buclaw via Digitalmars-d wrote: Right, it's a quirk of the CPU. It's a precision quirk of floating point that has to be defined, and different CPUs follow different definitions. Within IEEE754 it can of course also differ, since it does not prevent higher precision than specified. http://en.wikipedia.org/wiki/Denormal_number
Re: std.math performance (SSE vs. real)
On Friday, 4 July 2014 at 01:26:37 UTC, Walter Bright wrote: The issues you presented are subjective and a matter of opinion. Regardless of the state of D, I'm not the type who wilts at an issue or two - I work around it. And so does everyone else who does production work. If you sit around waiting for arbitrary perfection, you'll never get any work done. I don't care that my truck has dings in it, either, it's a truck and it's useful for what I need it for :-) Well said, and that's exactly how things tend to works. --- Paolo
Re: std.math performance (SSE vs. real)
On Friday, 4 July 2014 at 01:26:37 UTC, Walter Bright wrote: If you sit around waiting for arbitrary perfection, you'll never get any work done. I don't care that my truck has dings in it, either, it's a truck and it's useful for what I need it for :-) Even though a Tesla is of no more use than your old ugly truck, I still favor the former. :P
Re: std.math performance (SSE vs. real)
On Thursday, 3 July 2014 at 14:26:51 UTC, Iain Buclaw via Digitalmars-d wrote: It's also a handy coincidence that for many platforms the targets largest supported FP and *double* type happen to be the same too. Out of curiosity, how is C long double interpreted on those platforms? Just doesn't exist, or is interpreted as the same as double? What's concerning me here is that you've posted at least one example platform where the C long double is _not_ the same as the largest FP type. Now, it makes sense to me that the spec _could_ be, real == largest hardware-supported FP type, and it makes sense that the spec could be, real == C long double for the platform. But it seems quite apparent that it can't mean both, and that there needs to be a firm decision about which we want it to be.
Re: std.math performance (SSE vs. real)
On Thursday, 3 July 2014 at 00:03:47 UTC, Walter Bright wrote: On 7/2/2014 3:15 PM, Sean Kelly wrote: On Wednesday, 2 July 2014 at 21:44:17 UTC, Walter Bright wrote: C long double == D real for 32 and 64 bit OSX, Linux, and FreeBSD. And it's 'double double' on PPC and 128 bit quad on SPARC. Assuming D targets those platforms, what will be the behavior there? Per the D spec, 'real' will be the longest type supported by the native hardware. This is the problem. If that is the case, it is USELESS. We *must* change that definition. What is the longest type supported by the native hardware? I don't know what that means, and I don't think it even makes sense. For example, Sparc has 128-bit quads, but they only have partial support. Effectively. they are emulated. Why on earth would you want to use an emulated type on some machines, but not on others? Perhaps the intention was the largest precision you can get for free, without sacrificing speed then that's not clearly defined. On x86-32, that was indeed 80 bits. But on other systems it doesn't have an obvious answer. On x86-64 it's not that simple. Nor on PPC or Sparc.
Re: std.math performance (SSE vs. real)
On 4 Jul 2014 10:40, Joseph Rushton Wakeling via Digitalmars-d digitalmars-d@puremagic.com wrote: On Thursday, 3 July 2014 at 14:26:51 UTC, Iain Buclaw via Digitalmars-d wrote: It's also a handy coincidence that for many platforms the targets largest supported FP and *double* type happen to be the same too. Out of curiosity, how is C long double interpreted on those platforms? Just doesn't exist, or is interpreted as the same as double? Same as double. What's concerning me here is that you've posted at least one example platform where the C long double is _not_ the same as the largest FP type. Now, it makes sense to me that the spec _could_ be, real == largest hardware-supported FP type, and it makes sense that the spec could be, real == C long double for the platform. But it seems quite apparent that it can't mean both, and that there needs to be a firm decision about which we want it to be. It's whatever you configure it to be. Essentially, I want to give porters maximum flexibility on this. Iain.
Re: std.math performance (SSE vs. real)
Walter Bright wrote in message news:lp26l3$qlk$1...@digitalmars.com... Per the D spec, 'real' will be the longest type supported by the native hardware. So if you were targeting a processor with only soft-float real would be undefined? Fixing the widths of the integers was a great idea, and we really should have done the same with the floating point types. We could easily have a library alias for what real currently means. Not only that, a marquee feature of D is interoperability with C. We'd need an AWFULLY good reason to throw that under the bus. Unfortunately it's a useless definition for portable interop with C++. real needs to always match the size and mangling of long double unless you want to stick workarounds all over the bindings. We have related problems with char/char/char and long/longlong/size_t, but luckily relatively few interfaces actually use long double.
Re: std.math performance (SSE vs. real)
On 4 Jul 2014 13:10, Daniel Murphy via Digitalmars-d digitalmars-d@puremagic.com wrote: Walter Bright wrote in message news:lp26l3$qlk$1...@digitalmars.com... Per the D spec, 'real' will be the longest type supported by the native hardware. So if you were targeting a processor with only soft-float real would be undefined? Fixing the widths of the integers was a great idea, and we really should have done the same with the floating point types. We could easily have a library alias for what real currently means. FP types are fixed. float is 32bit, double 64bit. Not only that, a marquee feature of D is interoperability with C. We'd need an AWFULLY good reason to throw that under the bus. Unfortunately it's a useless definition for portable interop with C++. real needs to always match the size and mangling of long double unless you want to stick workarounds all over the bindings. We have related problems with char/char/char and long/longlong/size_t, but luckily relatively few interfaces actually use long double. What 's the mangling problem with long double? There's only *one* long double.
Re: std.math performance (SSE vs. real)
On Friday, 4 July 2014 at 01:26:37 UTC, Walter Bright wrote: The issues you presented are subjective and a matter of opinion. Well, one has to agree on a definition for a start! :) If you sit around waiting for arbitrary perfection, you'll never get any work done. I pick the most stable tool for the job. Meaning I usually end up with C, conservative use of C++, Python 2.7, Javascript, SQL or XSLT… :-P Rarely D and occasionally Dart (which isn't particularly stable either and is rejected beacuase of it) and Php (which is pretty stable). It's a matter of priority. If the D maintainers don't care about reaching a stable state, at the expense of scope and features, then it will never be the best tool for the job. I regret that.
Re: std.math performance (SSE vs. real)
Ola Fosheim Grøstad: If the D maintainers don't care about reaching a stable state, at the expense of scope and features, Don't be silly, D devs care a lot about reaching stability, fixing bugs, etc. Bye, bearophile
Re: std.math performance (SSE vs. real)
Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com wrote in message news:mailman.3265.1404477916.2907.digitalmar...@puremagic.com... FP types are fixed. float is 32bit, double 64bit. That's 2/3. What 's the mangling problem with long double? There's only *one* long double. long double may not be the same size as D's real, eg in msvc it's 64-bit. You can still still call these functions from D using double in C, but the mangling will not match in C++.
Re: std.math performance (SSE vs. real)
On 4 July 2014 14:01, Daniel Murphy via Digitalmars-d digitalmars-d@puremagic.com wrote: Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com wrote in message news:mailman.3265.1404477916.2907.digitalmar...@puremagic.com... FP types are fixed. float is 32bit, double 64bit. That's 2/3. What 's the mangling problem with long double? There's only *one* long double. ' long double may not be the same size as D's real, eg in msvc it's 64-bit. You can still still call these functions from D using double in C, but the mangling will not match in C++. You're confusing long double with size_t. I did a cursory look up msvc++ mangling, and long double is always 'O'. The itanium spec says that long double is 'e' - unless 128bits in which case it is 'g'. Iain.
Re: std.math performance (SSE vs. real)
Iain Buclaw via Digitalmars-d wrote in message news:mailman.3268.1404486824.2907.digitalmar...@puremagic.com... You're confusing long double with size_t. I did a cursory look up msvc++ mangling, and long double is always 'O'. The itanium spec says that long double is 'e' - unless 128bits in which case it is 'g'. Yes, so msvc++ has two 64-bit floating types with different manglings, and D has one. D does not have a type that can be used to match long double's mangling with msvc.
Re: std.math performance (SSE vs. real)
On 4 July 2014 17:31, Daniel Murphy via Digitalmars-d digitalmars-d@puremagic.com wrote: Iain Buclaw via Digitalmars-d wrote in message news:mailman.3268.1404486824.2907.digitalmar...@puremagic.com... You're confusing long double with size_t. I did a cursory look up msvc++ mangling, and long double is always 'O'. The itanium spec says that long double is 'e' - unless 128bits in which case it is 'g'. Yes, so msvc++ has two 64-bit floating types with different manglings, and D has one. D does not have a type that can be used to match long double's mangling with msvc. No, msvc++ has one mangle type. Itanium has two, but you're never going to run into a situation where there's a conflict because long double can't be both 80bit and 128bit at the same time!
Re: std.math performance (SSE vs. real)
On 7/4/2014 1:37 AM, Max Samukha wrote: On Friday, 4 July 2014 at 01:26:37 UTC, Walter Bright wrote: If you sit around waiting for arbitrary perfection, you'll never get any work done. I don't care that my truck has dings in it, either, it's a truck and it's useful for what I need it for :-) Even though a Tesla is of no more use than your old ugly truck, I still favor the former. :P You wouldn't use a Tesla for hauling!
Re: std.math performance (SSE vs. real)
On 7/4/2014 5:48 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: I pick the most stable tool for the job. Meaning I usually end up with C, conservative use of C++, Python 2.7, Javascript, SQL or XSLT… :-P Rarely D and occasionally Dart (which isn't particularly stable either and is rejected beacuase of it) and Php (which is pretty stable). It's a matter of priority. If the D maintainers don't care about reaching a stable state, at the expense of scope and features, then it will never be the best tool for the job. I regret that. We care a great deal about that. C++, etc., is a much harder tool to get work done with. You'd have to judge that difficulty and work increase against the dealing with imperfections in D. It's a clear win for D.
Re: std.math performance (SSE vs. real)
On 7/4/2014 5:06 AM, Daniel Murphy wrote: Walter Bright wrote in message news:lp26l3$qlk$1...@digitalmars.com... Per the D spec, 'real' will be the longest type supported by the native hardware. So if you were targeting a processor with only soft-float real would be undefined? Fixing the widths of the integers was a great idea, and we really should have done the same with the floating point types. We could easily have a library alias for what real currently means. Again, I expect the implementor for Platform X to be able to make a solid judgement on what to do for that platform that makes the most sense. Not only that, a marquee feature of D is interoperability with C. We'd need an AWFULLY good reason to throw that under the bus. Unfortunately it's a useless definition for portable interop with C++. real needs to always match the size and mangling of long double unless you want to stick workarounds all over the bindings. We have related problems with char/char/char and long/longlong/size_t, Such problems disappear when common sense is applied. but luckily relatively few interfaces actually use long double. I really do not understand what the big problem is. It's trivial to interface with C code on Linux that accepts long doubles on all platforms D currently supports.
Re: std.math performance (SSE vs. real)
On 7/4/2014 3:38 AM, Don wrote: What is the longest type supported by the native hardware? I don't know what that means, and I don't think it even makes sense. Most of the time, it is quite clear. For example, Sparc has 128-bit quads, but they only have partial support. Effectively. they are emulated. Why on earth would you want to use an emulated type on some machines, but not on others? Emulation is not native support. Perhaps the intention was the largest precision you can get for free, without sacrificing speed then that's not clearly defined. On x86-32, that was indeed 80 bits. But on other systems it doesn't have an obvious answer. On x86-64 it's not that simple. Nor on PPC or Sparc. Yes, there is some degree of subjectivity on some platforms. I don't see a good reason for hamstringing the compiler dev with legalese for Platform X with legalese that isn't quite the right thing to do for X. I think the intention of the spec is clear, and the compiler implementor can be relied on to exercise good judgement.
Re: std.math performance (SSE vs. real)
On 7/4/2014 6:01 AM, Daniel Murphy wrote: long double may not be the same size as D's real, eg in msvc it's 64-bit. You can still still call these functions from D using double in C, but the mangling will not match in C++. You are correct in that VC++ mangles double as 'N' and long double as 'O' but both are implemented as doubles. This means that: void foo(long double d); is callable from D if it is compiled as C, but not as C++. This is not a language lawyer problem, as D isn't guaranteed to support all C++ mangling. As a practical problem, it would be pretty rare (since such code usually provides double overloads), and if it still was a problem a bit of adapter C++ code (a 1 liner) can be written.
Re: std.math performance (SSE vs. real)
On Friday, 4 July 2014 at 17:05:16 UTC, Walter Bright wrote: On 7/4/2014 3:38 AM, Don wrote: What is the longest type supported by the native hardware? I don't know what that means, and I don't think it even makes sense. Most of the time, it is quite clear. For example, Sparc has 128-bit quads, but they only have partial support. Effectively. they are emulated. Why on earth would you want to use an emulated type on some machines, but not on others? Emulation is not native support. Perhaps the intention was the largest precision you can get for free, without sacrificing speed then that's not clearly defined. On x86-32, that was indeed 80 bits. But on other systems it doesn't have an obvious answer. On x86-64 it's not that simple. Nor on PPC or Sparc. Yes, there is some degree of subjectivity on some platforms. I don't see a good reason for hamstringing the compiler dev with legalese for Platform X with legalese that isn't quite the right thing to do for X. I think the intention of the spec is clear, and the compiler implementor can be relied on to exercise good judgement. Who are these compiler implementers? Are you actually suggesting that, for example, ldc and gdc would seperately decide
Re: std.math performance (SSE vs. real)
On 7/4/2014 10:42 AM, John Colvin wrote: Who are these compiler implementers? Whoever decides to implement D for a particular platform. Are you actually suggesting that, for example, ldc and gdc would seperately decide I am confident they will exercise good judgement in making their implementation of D as useful as practical.
Re: std.math performance (SSE vs. real)
On Friday, 4 July 2014 at 12:59:41 UTC, bearophile wrote: If the D maintainers don't care about reaching a stable state, at the expense of scope and features, Don't be silly, D devs care a lot about reaching stability, fixing bugs, etc. But not to the extent that they are willing to limit the scope and features to get there in reasonable time for D2 (say 10 months), so the feature set is expanding and the scope of the standard library is too big for a stable mature library that is easy to use to be feasible as far as I can tell. Dart is going down the same path. It affects adoption, which in turn affects the eco system. Basically Dart pushed their commercial adoption two years into the future by not commiting to stable platform support, claming that they only support evergreen browsers, whatever that means. Which pretty much lets Google, Apple and Microsoft define platform stability. I'm not trying to be pushy or silly. I just want to know if the most probable path for an alternative system development language is a fork or spinning up a new project. Evolutionary development is great when there is great uncertainty and you need prototyping, but then you need to focus on getting to something that is tight, uniform, portable (future proof) and feasible with the available resources. A good starting point would be to get down to locking down the specs in a coherent and platform agnostic manner, then plan for making a mature toolset to support it. The D spec should be clear on what IEEE 754 compliance actually means and relate it to all probable scenarios. That would be a very useful exercise in decision making.
Re: std.math performance (SSE vs. real)
On 7/4/2014 12:07 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: The D spec should be clear on what IEEE 754 compliance actually means and relate it to all probable scenarios. I'm curious how that would affect anyone currently using dmd/gdc/ldc in getting professional work done.
Re: std.math performance (SSE vs. real)
On Friday, 4 July 2014 at 19:53:11 UTC, Walter Bright wrote: I'm curious how that would affect anyone currently using dmd/gdc/ldc in getting professional work done. It doesn't affect them since they are on x86 (until they want to use co-processor auto-vectorization). As far as I can tell, also Intel CPUs such as Phi are faster if you skip on IEEE754 conformance for denormal numbers. So I think this is a trend, backed empirically by CPUs by IBM, ARM and Intel. The most important factor is that it does affect the credibility of the spec. The spec is the vision that people either embrace or reject. For those devs who aren't happy with status quo having a credible spec that the team is committed to is important, because it says what outcome they can expect if they start contributing. There is very little incentive to contribute if you think that the current D incarnation is insufficient, unless the team specs out what D is to become. If you can commit to a spec for D2 that is final, then you can also plan for when D2 is done.
Re: std.math performance (SSE vs. real)
On 7/4/2014 1:13 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: If you can commit to a spec for D2 that is final, then you can also plan for when D2 is done. There's no such thing as done for a working language. C++, for example, is constantly in flux. Every release by every vendor alters which parts of the standard and draft standard it supports. Furthermore, the C/C++ Standards don't have much to say about how floating point works - how is that of any help in writing professional, stable fp code? Do we want to make the spec better? Yes. Does that impair professional use of D now? No. Do we accept pull requests on the spec to make it better? Yes. Have you contributed to any pull requests to improve the spec? Please, contribute to the things you care about, instead of suggesting in the n.g. that others should do it. That would be far more helpful.
Re: std.math performance (SSE vs. real)
On Friday, 4 July 2014 at 20:28:36 UTC, Walter Bright wrote: There's no such thing as done for a working language. C++, for example, is constantly in flux. Every release by every vendor alters which parts of the standard and draft standard it supports. And no sane devs rely on those experimental parts unless g++ or clang commits themselves to them. The C++ standard specs out things in advance at intervals specified in years, not weeks. Furthermore, the C/C++ Standards don't have much to say about how floating point works - how is that of any help in writing professional, stable fp code? You know that you are on your own and cannot make assumptions about conformance, and address it with code (like ifdefs). Do we want to make the spec better? Yes. Not make the spec better or bring it up to date with the implementation. Spec out the language so people know what the missing bits are. Please, contribute to the things you care about, instead of suggesting in the n.g. that others should do it. That would be far more helpful. That would imply a fork. And yes, I think that might be the most likely outcome that someone forks it. I don't believe in language design by a comittee. I think the language designers should spec out their vision. Let the community point out the flaws. Go back to the drawing board. Do some rounds. Then commit to it. I think that would attract more contribution to the core language development. I am interested in contributing code to make a good spec come to life, not to add noise to an endless contractual metamorphosis that never will lead to anything consistent and coherent.
Re: std.math performance (SSE vs. real)
On 7/4/2014 1:41 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Friday, 4 July 2014 at 20:28:36 UTC, Walter Bright wrote: There's no such thing as done for a working language. C++, for example, is constantly in flux. Every release by every vendor alters which parts of the standard and draft standard it supports. And no sane devs rely on those experimental parts unless g++ or clang commits themselves to them. The C++ standard specs out things in advance at intervals specified in years, not weeks. As I said, C++ vendors often implement things far in advance of spec approval, they do it piecemeal, and different vendors do things in different orders. C++ evangelists are constantly rewriting what C++ best practices are. To characterize all this churn as stablility is awfully charitable. Furthermore, the C/C++ Standards don't have much to say about how floating point works - how is that of any help in writing professional, stable fp code? You know that you are on your own and cannot make assumptions about conformance, and address it with code (like ifdefs). Uh-huh. And how much professional code have you seen that had #ifdef's for Vax fp in it? IBM fp? Future CPUs that don't exist yet? How many developers have access to a Vax to test their #ifdef's on? Next, consider how much C++ code breaks when ported from 32 to 64 bits. It's most of it, even mine, and I know what I'm doing. What you're implying is saying that when a spec says implementation defined then voila! the code is portable! Do we want to make the spec better? Yes. Not make the spec better or bring it up to date with the implementation. Spec out the language so people know what the missing bits are. Please contribute to those areas of the spec you feel need improvement. Non-specific statements like bring it up to date are not helpful. Please, contribute to the things you care about, instead of suggesting in the n.g. that others should do it. That would be far more helpful. That would imply a fork. And yes, I think that might be the most likely outcome that someone forks it. A pull request does not imply a fork. I don't believe in language design by a comittee. The only alternative is you believe I need to do all the work. This is not possible. I am not superman, nor am I expert at everything. Sadly, this also implies that there are no computer languages you believe in. You set an impossible standard. How can you possibly say you prefer C++, a classic design by committee language? I think the language designers should spec out their vision. Let the community point out the flaws. Go back to the drawing board. Do some rounds. Then commit to it. I think that would attract more contribution to the core language development. I'm asking you to contribute. These posts do not accomplish anything. Exhorting me to do more (I already work on D 24/7) cannot work. I am interested in contributing code to make a good spec come to life, not to add noise to an endless contractual metamorphosis that never will lead to anything consistent and coherent. Nothing will improve if you and others remain on the sidelines. Get out in front and make what you want to happen, happen.
Re: std.math performance (SSE vs. real)
On Thu, 3 Jul 2014 14:01:23 -0700 Jonathan M Davis via Digitalmars-d digitalmars-d@puremagic.com wrote: I'm fine with real varying from platform to platform depending on what makes sense for that platform, but I think that it should be clear what real is generally supposed to be (e.g. the largest floating point type that the hardware supports), but unless it's _guaranteed_ that real be the same as long double, I would strongly argue in favor of having an alias for long double rather than using real directly (much as it will likely be an alias to real in most cases). We already do that with c_long. Here: https://github.com/D-Programming-Language/druntime/pull/863 - Jonathan M Davis
Re: std.math performance (SSE vs. real)
On Friday, 4 July 2014 at 21:08:27 UTC, Walter Bright wrote:
rewriting what C++ best practices are. To characterize all
this churn as stablility is awfully charitable.
Pfft, a lot of performance C++ code is roughly in 1998 land
without exceptions and rtti.
Uh-huh. And how much professional code have you seen that had
#ifdef's for Vax fp in it? IBM fp? Future CPUs that don't exist
yet? How many developers have access to a Vax to test their
#ifdef's on?
It is not uncommon for portable DSP code to have ifdefs. It is
not uncommon to have ifdefs for extracting the mantissa etc.
Heck, even for uints you might need ifdefs, to account for
whether you have wrapping uints or not in phase counters.
(wrapping over 31 bits or 32 bits)
Considering that denormal numbers being flushed to zero is
non-standard and not uncommon, it would be wise to somehow
support it with version{}, so you can specify what assumptions a
particular function make. That way you might get not
implemented as a compile time error when porting to a new
platform.
What you're implying is saying that when a spec says
implementation defined then voila! the code is portable!
No, it says voila! the code is not portable and then you can
inject your own guards that might prevent it from compiling on
nonconforming platforms and let you know what you need to look at.
Sadly, this also implies that there are no computer languages
you believe in. You set an impossible standard. How can you
possibly say you prefer C++, a classic design by committee
language?
I don't prefer it. I think it sucks, but it is the only viable
choice if you want to create a scalable game or virtual world
server. And since C++ is the crappy shit it is, you usually have
to build a language on top of it to keep the server stable and
modifiable and stay sane. A key benefit of a tighter version of D
would be to avoid that extra layer IMO.
I'm asking you to contribute. These posts do not accomplish
anything. Exhorting me to do more (I already work on D 24/7)
cannot work.
Maybe you and Andrei could consider having other people do the
stuff you don't have to do, but that other people can take care
of? Because I think you and Andrei are the only ones who can spec
out the changes that would make D a clean delightful language to
use and get acceptance for it in the community.
The alternative is to fork it, cut down on features, clean up the
syntax for DSL purposes, rip out the GC and add transactional
memory support. I think the current process is too slow for
outsiders to get D to production level in the domains where speed
and stability truly matters.
Re: std.math performance (SSE vs. real)
On 3 Jul 2014 01:50, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 7/2/2014 2:28 PM, Iain Buclaw via Digitalmars-d wrote: On 2 July 2014 19:58, via Digitalmars-d digitalmars-d@puremagic.com wrote: I don't really understand the reasoning here. Is D Intel x86 specific? Yes it is, more than you might realise. I've been spending the last 4 years breaking it to be platform agnostic. :o) I think you're conflating dmd with D. I suppose I am just a bit. At the time I was thinking about the spec on _argptr (which has been fixed), __simd and intrinsics.
Re: std.math performance (SSE vs. real)
On 3 Jul 2014 04:50, Sean Kelly via Digitalmars-d digitalmars-d@puremagic.com wrote: On Thursday, 3 July 2014 at 01:13:13 UTC, H. S. Teoh via Digitalmars-d wrote: I'm not sure I understand how removing support 80-bit floats hurts interoperability with C? I thought none of the standard C float types map to the x87 80-bit float? The C spec never says anything specific about representation because it's meant to target anything, but the x86 and AMD64 ABIs basically say that long double is 80-bit for calculations. The x86 spec says that the type is stored in 96 bits though, and the AMD64 spec says they're stored in 128 bits for alignment purposes. I'm still unclear whether we're aiming for C interoperability or hardware support though, based on Walter's remark about SPARC and PPC. There, 'long double' is represented differently but is not backed by specialized hardware, so I'm guessing D would make 'real' 64-bits on these platforms and break compatibility with C. So... I guess we really do need a special alias for C compatibility, and this can map to whatever intrinsic type the applicable compiler supports for that platform. I take the spec to mean that I can map float, double, and real to the native C types for float, double, and long double - or in jargon terms, the native single, double, and extended (or quad if the user or backend requests it) types. Certainly I have implemented my bits of std.math with real == double and real == quad in mind. PPC will have to wait, but it is easy enough to identify doubledouble reals in CTFE. Iain.
Re: std.math performance (SSE vs. real)
On Wednesday, 2 July 2014 at 12:24:51 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 2 July 2014 at 12:16:18 UTC, Wanderer wrote: D is not even production ready, so why should there be? Who in their right mind would use a language in limbo for building a serious operating system or do embedded work? You need language stability and compiler maturity first. That's plain wrong: here at SR Labs we are using it in production, and making money over it. --- Paolo
Re: std.math performance (SSE vs. real)
On 7/2/2014 6:11 PM, H. S. Teoh via Digitalmars-d wrote: What should we do in the case of hardware that offers strange hardware types, like a hypothetical 48-bit floating point type? Should D offer a built-in type for that purpose, even if it only exists on a single chip that's used by 0.01% of the community? I'd leave that decision up to the guy implementing the D compiler for that chip. Not only that, a marquee feature of D is interoperability with C. We'd need an AWFULLY good reason to throw that under the bus. I'm not sure I understand how removing support 80-bit floats hurts interoperability with C? I thought none of the standard C float types map to the x87 80-bit float? (I'm not opposed to keeping real as 80-bit on x87, but I just don't understand what this has to do with C interoperability.) For the 4th time in this thread, the C ABI for x86 32 and 64 bit OSX, Linux, and FreeBSD maps long double to 80 bit reals. How can you call a C function: int foo(long double r); ??
Re: std.math performance (SSE vs. real)
On 7/2/2014 11:38 PM, Iain Buclaw via Digitalmars-d wrote: I suppose I am just a bit. At the time I was thinking about the spec on _argptr (which has been fixed), __simd and intrinsics. You do have a good point with those aspects.
Re: std.math performance (SSE vs. real)
On 7/2/2014 8:48 PM, Sean Kelly wrote: I'm still unclear whether we're aiming for C interoperability or hardware support though, based on Walter's remark about SPARC and PPC. There, 'long double' is represented differently but is not backed by specialized hardware, so I'm guessing D would make 'real' 64-bits on these platforms and break compatibility with C. So... I guess we really do need a special alias for C compatibility, and this can map to whatever intrinsic type the applicable compiler supports for that platform. What is unclear about being able to call a C function declared as: int foo(long double r); from D?
Re: std.math performance (SSE vs. real)
On Thursday, 3 July 2014 at 00:49:33 UTC, Walter Bright wrote: On 7/2/2014 2:28 PM, Iain Buclaw via Digitalmars-d wrote: On 2 July 2014 19:58, via Digitalmars-d digitalmars-d@puremagic.com wrote: I don't really understand the reasoning here. Is D Intel x86 specific? Yes it is, more than you might realise. I've been spending the last 4 years breaking it to be platform agnostic. :o) I think you're conflating dmd with D. And IEEE 754 is a standard. I understand what you're saying here, which is that any conflation of D with x86 is a fault in the implementation rather than the spec, but at the end of the day, D lives by its implementation. It's not just about what the dmd backend supports per se, but about what assumptions that leads people to make when writing code for the frontend, runtime and standard library. Iain has done some heroic work in the last year going through compiler frontend, runtime and Phobos and correcting code with faulty assumptions such as real == 80 bit floating point (which IIRC was often made as a general assumption even though it's x86-specific).
Re: std.math performance (SSE vs. real)
On Wed, 02 Jul 2014 23:56:21 -0700 Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 7/2/2014 8:48 PM, Sean Kelly wrote: I'm still unclear whether we're aiming for C interoperability or hardware support though, based on Walter's remark about SPARC and PPC. There, 'long double' is represented differently but is not backed by specialized hardware, so I'm guessing D would make 'real' 64-bits on these platforms and break compatibility with C. So... I guess we really do need a special alias for C compatibility, and this can map to whatever intrinsic type the applicable compiler supports for that platform. What is unclear about being able to call a C function declared as: int foo(long double r); from D? I don't think that there's anything unclear about that. The problem is that if real is supposed to be the largest hardware supported floating point type, then that doesn't necessarily match long double. It happens to on x86 and x86_64, but it doesn't on other architectures. So, is real the same as C's long double, or is it the same as the largest floating point type supported by the hardware? We have erroneously treated them as the same thing, because they happen to be the same thing on x86 hardware. But D needs to work on more than just x86 and x86_64, even if dmd doesn't. We already have aliases such as c_long to deal with C types. I don't think that it would be all that big a deal to make it so that real was specifically the largest supported hardware type and then have c_long_double for interacting with C. - Jonathan M Davis
Re: std.math performance (SSE vs. real)
On 3 July 2014 11:49, Jonathan M Davis via Digitalmars-d digitalmars-d@puremagic.com wrote: On Wed, 02 Jul 2014 23:56:21 -0700 Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 7/2/2014 8:48 PM, Sean Kelly wrote: I'm still unclear whether we're aiming for C interoperability or hardware support though, based on Walter's remark about SPARC and PPC. There, 'long double' is represented differently but is not backed by specialized hardware, so I'm guessing D would make 'real' 64-bits on these platforms and break compatibility with C. So... I guess we really do need a special alias for C compatibility, and this can map to whatever intrinsic type the applicable compiler supports for that platform. What is unclear about being able to call a C function declared as: int foo(long double r); from D? I don't think that there's anything unclear about that. The problem is that if real is supposed to be the largest hardware supported floating point type, then that doesn't necessarily match long double. It happens to on x86 and x86_64, but it doesn't on other architectures. So, is real the same as C's long double, or is it the same as the largest floating point type supported by the hardware? We have erroneously treated them as the same thing, because they happen to be the same thing on x86 hardware. But D needs to work on more than just x86 and x86_64, even if dmd doesn't. The spec should be clearer on that. The language should respect the long double ABI of the platform it is targeting - so if the compiler is targeting a real=96bit system, but the max supported on the chip is 128bit, the compiler should *still* map real to the 96bit long doubles, unless explicitly told otherwise on the command-line. The same goes to other ABI aspects of real, for instance, if you are targeting an ABI where scalar 64bit operations are done in Neon, then the compiler adheres to that (though I'd hope that people stick to defaults and not do this, because the cost of moving data from core registers to neon is high). Regards Iain
Re: std.math performance (SSE vs. real)
On Thursday, 3 July 2014 at 11:21:34 UTC, Iain Buclaw via Digitalmars-d wrote: The spec should be clearer on that. The language should respect the long double ABI of the platform it is targeting - so if the compiler is targeting a real=96bit system, but the max supported on the chip is 128bit, the compiler should *still* map real to the 96bit long doubles, unless explicitly told otherwise on the command-line. This would be a change in the standard, no? The long double ABI of the target platform is not necessarily the same as the current definition of real as the largest hardware-supported floating-point type. I can't help but feel that this is another case where the definition of real in the D spec, and its practical use in the implementation, have wound up in conflict because of assumptions made relative to x86, where it's simply a nice coincidence that the largets hardware-supported FP and the long double type happen to be the same.
Re: std.math performance (SSE vs. real)
On 3 July 2014 14:51, Joseph Rushton Wakeling via Digitalmars-d digitalmars-d@puremagic.com wrote: On Thursday, 3 July 2014 at 11:21:34 UTC, Iain Buclaw via Digitalmars-d wrote: The spec should be clearer on that. The language should respect the long double ABI of the platform it is targeting - so if the compiler is targeting a real=96bit system, but the max supported on the chip is 128bit, the compiler should *still* map real to the 96bit long doubles, unless explicitly told otherwise on the command-line. This would be a change in the standard, no? The long double ABI of the target platform is not necessarily the same as the current definition of real as the largest hardware-supported floating-point type. I can't help but feel that this is another case where the definition of real in the D spec, and its practical use in the implementation, have wound up in conflict because of assumptions made relative to x86, where it's simply a nice coincidence that the largets hardware-supported FP and the long double type happen to be the same. It's also a handy coincidence that for many platforms the targets largest supported FP and *double* type happen to be the same too.
Re: std.math performance (SSE vs. real)
On Thursday, 3 July 2014 at 06:56:20 UTC, Walter Bright wrote: On 7/2/2014 8:48 PM, Sean Kelly wrote: I'm still unclear whether we're aiming for C interoperability or hardware support though, based on Walter's remark about SPARC and PPC. There, 'long double' is represented differently but is not backed by specialized hardware, so I'm guessing D would make 'real' 64-bits on these platforms and break compatibility with C. So... I guess we really do need a special alias for C compatibility, and this can map to whatever intrinsic type the applicable compiler supports for that platform. What is unclear about being able to call a C function declared as: int foo(long double r); from D? This: On Thursday, 3 July 2014 at 00:03:47 UTC, Walter Bright wrote: On 7/2/2014 3:15 PM, Sean Kelly wrote: On Wednesday, 2 July 2014 at 21:44:17 UTC, Walter Bright wrote: C long double == D real for 32 and 64 bit OSX, Linux, and FreeBSD. And it's 'double double' on PPC and 128 bit quad on SPARC. Assuming D targets those platforms, what will be the behavior there? Per the D spec, 'real' will be the longest type supported by the native hardware.
Re: std.math performance (SSE vs. real)
On 7/3/2014 8:36 AM, Sean Kelly wrote: Per the D spec, 'real' will be the longest type supported by the native hardware. It's not necessary that real be long double - but it is necessary that long double be callable from D. Case in point: long double on Win64 is accessible with D's double, but D also supports 80 bit real.
Re: std.math performance (SSE vs. real)
On 7/3/2014 3:49 AM, Jonathan M Davis via Digitalmars-d wrote: I don't think that there's anything unclear about that. The problem is that if real is supposed to be the largest hardware supported floating point type, then that doesn't necessarily match long double. It happens to on x86 and x86_64, but it doesn't on other architectures. As it turns out, C compilers tend to use long double for that. So there's no issue. In any case, it's up to the person porting the D compiler to that platform to make these decisions. For another case, D for Win64 maps real to 80 bits, despite VC++ mapping long double to 64 bits. This is compatible with the D spec, because you are still able to call C functions typed as int foo(long double r) because D's double works for that. I think that some common sense on a case by case basis for each platform should work fine.
Re: std.math performance (SSE vs. real)
On Thursday, 3 July 2014 at 19:47:32 UTC, Walter Bright wrote: On 7/3/2014 8:36 AM, Sean Kelly wrote: Per the D spec, 'real' will be the longest type supported by the native hardware. It's not necessary that real be long double - but it is necessary that long double be callable from D. Case in point: long double on Win64 is accessible with D's double, but D also supports 80 bit real. That makes it seem like we are compatible by accident rather than by design.
Re: std.math performance (SSE vs. real)
On Thu, 03 Jul 2014 12:45:17 -0700 Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 7/3/2014 3:49 AM, Jonathan M Davis via Digitalmars-d wrote: I don't think that there's anything unclear about that. The problem is that if real is supposed to be the largest hardware supported floating point type, then that doesn't necessarily match long double. It happens to on x86 and x86_64, but it doesn't on other architectures. As it turns out, C compilers tend to use long double for that. So there's no issue. In any case, it's up to the person porting the D compiler to that platform to make these decisions. For another case, D for Win64 maps real to 80 bits, despite VC++ mapping long double to 64 bits. This is compatible with the D spec, because you are still able to call C functions typed as int foo(long double r) because D's double works for that. I think that some common sense on a case by case basis for each platform should work fine. I'm fine with real varying from platform to platform depending on what makes sense for that platform, but I think that it should be clear what real is generally supposed to be (e.g. the largest floating point type that the hardware supports), but unless it's _guaranteed_ that real be the same as long double, I would strongly argue in favor of having an alias for long double rather than using real directly (much as it will likely be an alias to real in most cases). We already do that with c_long. - Jonathan M Davis
Re: std.math performance (SSE vs. real)
On Thursday, 3 July 2014 at 21:01:43 UTC, Jonathan M Davis via Digitalmars-d wrote: I'm fine with real varying from platform to platform depending on what makes sense for that platform, but I think that it should be clear what real is generally supposed to be (e.g. the largest floating point type that the hardware supports), but unless it's _guaranteed_ that real be the same as long double, I would strongly argue in favor of having an alias for long double rather than using real directly (much as it will likely be an alias to real in most cases). We already do that with c_long. I'm inclined to agree. From what's been said, I suspect that on SPARC, 'real' would be an alias of 'double', and c_long_double would be an alias of some intrinsic type provided by the compiler, since there is no D equivalent for the IEEE 754 binary128 type. The alternative, making c_long_double a struct used for marshaling data into and out of the C format, doesn't seem terribly appealing.
Re: std.math performance (SSE vs. real)
On Wednesday, 2 July 2014 at 21:45:41 UTC, Walter Bright wrote: On 7/2/2014 5:24 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: D is not even production ready, Of course it is. Not by my definition of production ready: 1. Not stable or up to date language spec. 2. Outstanding significant issues in the bug tracker. 3. No mature compiler. 4. No mature runtime. 5. No stable std library. 6. No entity/vendor that provides support/maintenance for a specific version of D for a specified period of time. Would you use D for building software to ship with hardware appliances? I would not.
Re: std.math performance (SSE vs. real)
On 3 July 2014 22:43, via Digitalmars-d digitalmars-d@puremagic.com wrote: On Wednesday, 2 July 2014 at 21:45:41 UTC, Walter Bright wrote: On 7/2/2014 5:24 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: D is not even production ready, Of course it is. Not by my definition of production ready: 1. Not stable or up to date language spec. 2. Outstanding significant issues in the bug tracker. 3. No mature compiler. 4. No mature runtime. 5. No stable std library. 6. No entity/vendor that provides support/maintenance for a specific version of D for a specified period of time. You must know something I don't. :o)
Re: std.math performance (SSE vs. real)
On Thu, Jul 03, 2014 at 09:43:38PM +, via Digitalmars-d wrote: On Wednesday, 2 July 2014 at 21:45:41 UTC, Walter Bright wrote: On 7/2/2014 5:24 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: D is not even production ready, Of course it is. Not by my definition of production ready: [...] 2. Outstanding significant issues in the bug tracker. [...] I find this particular statement rather amusing. At my day job I work with enterprise software, which is currently running on dedicated hardware sold to major corporate customers worldwide. To say that the state of the bug tracker barely even begins to approach the state of D's bugtracker, would be the understatement of the century. We have so many outstanding bugs, ranging from minor to subtle-but-nasty to major design problems, that the PTBs have given up on trying to rein in the bug count, and have resorted to measures like closing bugs due to inactivity. The number of outstanding significant issues that get postponed past releases due to lack of resources, is enough to send chills down one's back, if he has any sense of pride in his work at all. Yet this bug-ridden software was deemed production ready (whatever that means), and is in fact running in mission-critical services on customer sites. By comparison, the state of D's bug tracker looks a lot more promising. T -- Political correctness: socially-sanctioned hypocrisy.
Re: std.math performance (SSE vs. real)
On 7/3/2014 2:43 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: Would you use D for building software to ship with hardware appliances? Yes. I would not. The issues you presented are subjective and a matter of opinion. Regardless of the state of D, I'm not the type who wilts at an issue or two - I work around it. And so does everyone else who does production work. If you sit around waiting for arbitrary perfection, you'll never get any work done. I don't care that my truck has dings in it, either, it's a truck and it's useful for what I need it for :-)
Re: std.math performance (SSE vs. real)
On 7/3/2014 1:30 PM, Tofu Ninja wrote: On Thursday, 3 July 2014 at 19:47:32 UTC, Walter Bright wrote: On 7/3/2014 8:36 AM, Sean Kelly wrote: Per the D spec, 'real' will be the longest type supported by the native hardware. It's not necessary that real be long double - but it is necessary that long double be callable from D. Case in point: long double on Win64 is accessible with D's double, but D also supports 80 bit real. That makes it seem like we are compatible by accident rather than by design. ?? I see nothing wrong with it, and it was on purpose.
Re: std.math performance (SSE vs. real)
On 1 July 2014 20:36, via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 1 July 2014 at 16:58:55 UTC, Walter Bright wrote: Click on compiling for strict IEEE conformance It also states that compliance affect performance. not IEEE754 compliant. VPF is almost compliant, but does not support subnormal numbers and flush them to zero. Which can be a disaster… It wouldn't be any different if the D spec says floating point is, ya know, whatevah. You can't fix stuff like this in the spec. Well, the difference is that you can make VPF mostly compliant, but that means you trap subnormal numbers and fix it in software. Which affects performance. If the specs require IEEE754 compliance then you default to software emulation and have to turn it off through compiler switches. Here is another example: the parallella Coprocessor from Adapteva: «The CPU is compatible with the IEEE-754 single-precision format, with the following exceptions: - No support for inexact flags. - NAN inputs generate an invalid exception and return a quiet NAN. When one or both of the inputs are NANs, the sign bit of the operation is set as an XOR of the signs of the input sign bits. - Denormal operands are flushed to zero when input to a computation unit and do not generate an underflow exception. Any denormal or underflow result from an arithmetic operation is flushed to zero and an underflow exception is generated. - Round-to-±infinity is not supported.» The crucial thing here is that the layout of float/double types are IEEE 754 are compatible. :) These behaviours you describe only affect the FP control functions in std.math, which are the only thing platform specific, and can only be written in inline assembly anyway... Regards Iain
Re: std.math performance (SSE vs. real)
On Tuesday, 1 July 2014 at 17:00:30 UTC, Walter Bright wrote: On 7/1/2014 3:26 AM, Don wrote: Yes, it's complicated. The interesting thing is that there are no 128 bit registers. The temporaries exist only while the FMA operation is in progress. You cannot even preserve them between consecutive FMA operations. An important consequence is that allowing intermediate calculations to be performed at higher precision than the operands, is crucial, and applies outside of x86. This is something we've got right. But it's not possible to say that the intermediate calculations are done at the precision of 'real'. This is the semantics which I think we currently have wrong. Our model is too simplistic. On modern x86, calculations on float operands may have intermediate calculations done at only 32 bits (if using straight SSE), 80 bits (if using x87), or 64 bits (if using float FMA). And for double operands, they may be 64 bits, 80 bits, or 128 bits. Yet, in the FMA case, non-FMA operations will be performed at lower precision. It's entirely possible for all three intermediate precisions to be active at the same time! I'm not sure that we need to change anything WRT code generation. But I think our style recommendations aren't quite right. And we have at least one missing primitive operation (discard all excess precision). What do you recommend? It needs some thought. But some things are clear. Definitely, discarding excess precision is a crucial operation. C and C++ tried to do it implicitly with sequence points, but that kills optimisation possibilities so much that compilers don't respect it. I think it's actually quite similar to write barriers in multithreaded programming. C got it wrong, but we're currently in an even worse situation because it doesn't necessarily happen at all. We need a builtin operation -- and not in std.math, this is as crucial as addition, and it's purely a signal to the optimiser. It's very similar to a casting operation. I wonder if we can do it as an attribute? .exact_float, .restrict_float, .force_float, .spill_float or something similar? With D's current floating point semantics, it's actually impossible to write correct floating-point code. Everything that works right now, is technically only working by accident. But if we get this right, we can have very nice semantics for when things like FMA are allowed to happen -- essentially the optimiser would have free reign between these explicit discard_excess_precision sequence points. After that, I'm a bit less sure. It does seem to me that we're trying to make 'real' do double-duty as meaning both x87 80 bit floating-point number and also as something like a storage class that is specific to double: compiler, don't discard excess precision. Which are both useful concepts, but aren't identical. The two concepts did coincide on x86 32-bit, but they're different on x86-64. I think we need to distinguish the two. Ideally, I think we'd have a __real80 type. On x86 32 bit this would be the same as 'real', while on x86-64 __real80 would be available but probably 'real' would alias to double. But I'm a lot less certain about this.
Re: std.math performance (SSE vs. real)
On 2 July 2014 09:53, Don via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Tuesday, 1 July 2014 at 17:00:30 UTC, Walter Bright wrote:
On 7/1/2014 3:26 AM, Don wrote:
Yes, it's complicated. The interesting thing is that there are no 128 bit
registers. The temporaries exist only while the FMA operation is in
progress.
You cannot even preserve them between consecutive FMA operations.
An important consequence is that allowing intermediate calculations to be
performed at higher precision than the operands, is crucial, and applies
outside
of x86. This is something we've got right.
But it's not possible to say that the intermediate calculations are done
at the
precision of 'real'. This is the semantics which I think we currently
have
wrong. Our model is too simplistic.
On modern x86, calculations on float operands may have intermediate
calculations
done at only 32 bits (if using straight SSE), 80 bits (if using x87), or
64 bits
(if using float FMA). And for double operands, they may be 64 bits, 80
bits, or
128 bits.
Yet, in the FMA case, non-FMA operations will be performed at lower
precision.
It's entirely possible for all three intermediate precisions to be active
at the
same time!
I'm not sure that we need to change anything WRT code generation. But I
think
our style recommendations aren't quite right. And we have at least one
missing
primitive operation (discard all excess precision).
What do you recommend?
It needs some thought. But some things are clear.
Definitely, discarding excess precision is a crucial operation. C and C++
tried to do it implicitly with sequence points, but that kills
optimisation possibilities so much that compilers don't respect it. I think
it's actually quite similar to write barriers in multithreaded programming.
C got it wrong, but we're currently in an even worse situation because it
doesn't necessarily happen at all.
We need a builtin operation -- and not in std.math, this is as crucial as
addition, and it's purely a signal to the optimiser. It's very similar to a
casting operation. I wonder if we can do it as an attribute? .exact_float,
.restrict_float, .force_float, .spill_float or something similar?
With D's current floating point semantics, it's actually impossible to write
correct floating-point code. Everything that works right now, is technically
only working by accident.
But if we get this right, we can have very nice semantics for when things
like FMA are allowed to happen -- essentially the optimiser would have free
reign between these explicit discard_excess_precision sequence points.
Fixing this is the goal I assume. :)
---
import std.stdio;
void test(double x, double y)
{
double y2 = x + 1.0;
if (y != y2) writeln(error); // Prints 'error' under -O2
}
void main()
{
immutable double x = .012; // Removing 'immutable' and it works.
double y = x + 1.0;
test(x, y);
}
---
After that, I'm a bit less sure. It does seem to me that we're trying to
make 'real' do double-duty as meaning both x87 80 bit floating-point
number and also as something like a storage class that is specific to
double: compiler, don't discard excess precision. Which are both useful
concepts, but aren't identical. The two concepts did coincide on x86 32-bit,
but they're different on x86-64. I think we need to distinguish the two.
Ideally, I think we'd have a __real80 type. On x86 32 bit this would be the
same as 'real', while on x86-64 __real80 would be available but probably
'real' would alias to double. But I'm a lot less certain about this.
There are flags for that in gdc:
-mlong-double-64
-mlong-double-80
-mlong-double-128
Re: std.math performance (SSE vs. real)
On Wednesday, 2 July 2014 at 08:52:25 UTC, Iain Buclaw via Digitalmars-d wrote: The crucial thing here is that the layout of float/double types are IEEE 754 are compatible. :) That's nice of course, if you import/export, but hardly the only crucial thing. Implied correctness and warnings when assumptions break is also important… These behaviours you describe only affect the FP control functions in std.math, which are the only thing platform specific, and can only be written in inline assembly anyway... It affects the backend. It affects vectorization. (NEON is not IEEE754 AFAIK) It affects what a conforming D compiler is allowed to do. It affects versioning. E.g. you can have a flags IEEE754_STRICT or IEE754_HAS_NAN etc and use versioning that dectects the wrong compiler-mode.
Re: std.math performance (SSE vs. real)
On Tuesday, 1 July 2014 at 19:36:26 UTC, Ola Fosheim Grøstad wrote: Besides, Java and Javascript, for example, both require IEEE conformance. But they aren't system level programming languages… and we probably cannot expect future many-core processors or transputer-like processors to waste die space in order to conform. So it's okay for system level programming languages to produce numeric garbage when it comes to floating points? ;-) Sorry, couldn't resist. Some people keep claiming that D is a system level programming language despite there is no single OS and no single hardware driver written in D yet. Which sorta puts D and Java into the same boat. Besides - gasp! - Java *is* a system level programming language after all. There are platforms/devices which support Java bytecode natively. For system programming, it's extra important that the same algorithm produces exactly the same results on different environments. And the speed is not always the most important factor.
Re: std.math performance (SSE vs. real)
On Wednesday, 2 July 2014 at 12:16:18 UTC, Wanderer wrote: So it's okay for system level programming languages to produce numeric garbage when it comes to floating points? ;-) System level programming languages provide direct easy access to the underlying hardware foundation. Sorry, couldn't resist. Some people keep claiming that D is a system level programming language despite there is no single OS and no single hardware driver written in D yet. D is not even production ready, so why should there be? Who in their right mind would use a language in limbo for building a serious operating system or do embedded work? You need language stability and compiler maturity first.
Re: std.math performance (SSE vs. real)
On 2 July 2014 12:42, via Digitalmars-d digitalmars-d@puremagic.com wrote: On Wednesday, 2 July 2014 at 08:52:25 UTC, Iain Buclaw via Digitalmars-d wrote: The crucial thing here is that the layout of float/double types are IEEE 754 are compatible. :) That's nice of course, if you import/export, but hardly the only crucial thing. Implied correctness and warnings when assumptions break is also important… These behaviours you describe only affect the FP control functions in std.math, which are the only thing platform specific, and can only be written in inline assembly anyway... It affects the backend. Only matters if you have to implement it in your backend It affects vectorization. (NEON is not IEEE754 AFAIK) Vectors are treated differently from floats It affects what a conforming D compiler is allowed to do. That depends what you mean be 'conforming'. It affects versioning. E.g. you can have a flags IEEE754_STRICT or IEE754_HAS_NAN etc and use versioning that dectects the wrong compiler-mode. Affects only library maintainers, but I haven't looked too much into what gcc offers as a platform regarding this. The ARM market is terrible, and it will certainly be the case that we *can't* have a one size fits all solution. But in the standard libraries we can certainly keep strictly in line with the most conforming chips, so if you wish to support X you may do so in a platform-specific fork. This is certainly not unusual for druntime (eg: minilibd) Regards Iain
Re: std.math performance (SSE vs. real)
On Wednesday, 2 July 2014 at 16:03:47 UTC, Iain Buclaw via Digitalmars-d wrote: Only matters if you have to implement it in your backend You have to implement it in the backend if D requires strict IEEE754 conformance? Vectors are treated differently from floats How can you then let the compiler vectorize? You can't. Meaning, your code will run very slow. It affects versioning. E.g. you can have a flags IEEE754_STRICT or IEE754_HAS_NAN etc and use versioning that dectects the wrong compiler-mode. Affects only library maintainers, but I haven't looked too much into what gcc offers as a platform regarding this. I don't agree. If your code produce denormal numbers then it matters a lot if they are forced to zero or not. Just think about divison by zero traps. Why would this only be a library issue? If you write portable code you shouldn't have to second guess what the compiler does. It either guarantees that denormal numbers are not flushed to zero, or it does not. If it does not then D does not require IEEE754 and you will have to think about this when you write your code. The ARM market is terrible, and it will certainly be the case that we *can't* have a one size fits all solution. But in the standard libraries we can certainly keep strictly in line with the most conforming chips, so if you wish to support X you may do so in a platform-specific fork. I don't really understand the reasoning here. Is D Intel x86 specific? Meaning, it is a system level programming language on x86 only and something arbitrary on other platforms? Either D requires IEEE754 strict mode, or it does not. It matters what the default is.
Re: std.math performance (SSE vs. real)
On 7/2/2014 1:53 AM, Don wrote: Definitely, discarding excess precision is a crucial operation. C and C++ tried to do it implicitly with sequence points, but that kills optimisation possibilities so much that compilers don't respect it. I think it's actually quite similar to write barriers in multithreaded programming. C got it wrong, but we're currently in an even worse situation because it doesn't necessarily happen at all. We need a builtin operation -- and not in std.math, this is as crucial as addition, and it's purely a signal to the optimiser. It's very similar to a casting operation. I wonder if we can do it as an attribute? .exact_float, .restrict_float, .force_float, .spill_float or something similar? With D's current floating point semantics, it's actually impossible to write correct floating-point code. Everything that works right now, is technically only working by accident. But if we get this right, we can have very nice semantics for when things like FMA are allowed to happen -- essentially the optimiser would have free reign between these explicit discard_excess_precision sequence points. This is easily handled without language changes by putting a couple builtin functions in druntime - roundToFloat() and roundToDouble(). Ideally, I think we'd have a __real80 type. On x86 32 bit this would be the same as 'real', while on x86-64 __real80 would be available but probably 'real' would alias to double. But I'm a lot less certain about this. I'm afraid that would not only break most D programs, but also interoperability with C.
Re: std.math performance (SSE vs. real)
On 2 July 2014 19:58, via Digitalmars-d digitalmars-d@puremagic.com wrote: On Wednesday, 2 July 2014 at 16:03:47 UTC, Iain Buclaw via Digitalmars-d wrote: Only matters if you have to implement it in your backend You have to implement it in the backend if D requires strict IEEE754 conformance? No, you don't. At least I just let the gcc backend take care of whatever behaviours occur. Which tend to be based around C as a baseline. Vectors are treated differently from floats How can you then let the compiler vectorize? You can't. Meaning, your code will run very slow. Easily - it does this for you so long as it determines that it is beneficial. The ARM market is terrible, and it will certainly be the case that we *can't* have a one size fits all solution. But in the standard libraries we can certainly keep strictly in line with the most conforming chips, so if you wish to support X you may do so in a platform-specific fork. I don't really understand the reasoning here. Is D Intel x86 specific? Yes it is, more than you might realise. I've been spending the last 4 years breaking it to be platform agnostic. :o) Regards Iain
Re: std.math performance (SSE vs. real)
On Wednesday, 2 July 2014 at 20:37:37 UTC, Walter Bright wrote: On 7/2/2014 1:53 AM, Don wrote: Ideally, I think we'd have a __real80 type. On x86 32 bit this would be the same as 'real', while on x86-64 __real80 would be available but probably 'real' would alias to double. But I'm a lot less certain about this. I'm afraid that would not only break most D programs, but also interoperability with C. Could you explain this? I didn't think we used 'real' to interface with C at all. We might need a type to match 'long double' in C, but what that is is already exceedingly variable. This would probably be another case for a special alias like we have for c_long.
Re: std.math performance (SSE vs. real)
On 2 July 2014 21:37, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 7/2/2014 1:53 AM, Don wrote: Definitely, discarding excess precision is a crucial operation. C and C++ tried to do it implicitly with sequence points, but that kills optimisation possibilities so much that compilers don't respect it. I think it's actually quite similar to write barriers in multithreaded programming. C got it wrong, but we're currently in an even worse situation because it doesn't necessarily happen at all. We need a builtin operation -- and not in std.math, this is as crucial as addition, and it's purely a signal to the optimiser. It's very similar to a casting operation. I wonder if we can do it as an attribute? .exact_float, .restrict_float, .force_float, .spill_float or something similar? With D's current floating point semantics, it's actually impossible to write correct floating-point code. Everything that works right now, is technically only working by accident. But if we get this right, we can have very nice semantics for when things like FMA are allowed to happen -- essentially the optimiser would have free reign between these explicit discard_excess_precision sequence points. This is easily handled without language changes by putting a couple builtin functions in druntime - roundToFloat() and roundToDouble(). Ideally, I think we'd have a __real80 type. On x86 32 bit this would be the same as 'real', while on x86-64 __real80 would be available but probably 'real' would alias to double. But I'm a lot less certain about this. I'm afraid that would not only break most D programs, but also interoperability with C. I think it could work with a very small selective list of operations. ie: - NegExp - CmpExp - CallExp to core.math intrinsics. Regards Iain.
Re: std.math performance (SSE vs. real)
On 7/2/2014 2:33 PM, Sean Kelly wrote: On Wednesday, 2 July 2014 at 20:37:37 UTC, Walter Bright wrote: I'm afraid that would not only break most D programs, but also interoperability with C. Could you explain this? I didn't think we used 'real' to interface with C at all. We might need a type to match 'long double' in C, but what that is is already exceedingly variable. This would probably be another case for a special alias like we have for c_long. C long double == D real for 32 and 64 bit OSX, Linux, and FreeBSD.
Re: std.math performance (SSE vs. real)
On 7/2/2014 5:24 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: D is not even production ready, Of course it is.
Re: std.math performance (SSE vs. real)
On Wednesday, 2 July 2014 at 21:44:17 UTC, Walter Bright wrote: On 7/2/2014 2:33 PM, Sean Kelly wrote: On Wednesday, 2 July 2014 at 20:37:37 UTC, Walter Bright wrote: I'm afraid that would not only break most D programs, but also interoperability with C. Could you explain this? I didn't think we used 'real' to interface with C at all. We might need a type to match 'long double' in C, but what that is is already exceedingly variable. This would probably be another case for a special alias like we have for c_long. C long double == D real for 32 and 64 bit OSX, Linux, and FreeBSD. And it's 'double double' on PPC and 128 bit quad on SPARC. Assuming D targets those platforms, what will be the behavior there? From my perspective, it seems like 'real' in D is utterly non-portable given its definition. I can see maybe using it in some cases if I knew I was targeting a specific architecture where the added precision was helpful, but for general purpose programming I'd always either use 'double' or some library-based type for extended precision, simply to have some assurance that my result would be predictable. Am I wrong in this?
Re: std.math performance (SSE vs. real)
On 7/2/2014 3:15 PM, Sean Kelly wrote: On Wednesday, 2 July 2014 at 21:44:17 UTC, Walter Bright wrote: C long double == D real for 32 and 64 bit OSX, Linux, and FreeBSD. And it's 'double double' on PPC and 128 bit quad on SPARC. Assuming D targets those platforms, what will be the behavior there? Per the D spec, 'real' will be the longest type supported by the native hardware. From my perspective, it seems like 'real' in D is utterly non-portable given its definition. I can see maybe using it in some cases if I knew I was targeting a specific architecture where the added precision was helpful, but for general purpose programming I'd always either use 'double' or some library-based type for extended precision, simply to have some assurance that my result would be predictable. Am I wrong in this? D is a systems programming language. That means it should have access to the hardware supported types. Portability is not the only goal - especially if that means least common denominator. People pay money for more powerful chips, and they'll want to use them. Not only that, a marquee feature of D is interoperability with C. We'd need an AWFULLY good reason to throw that under the bus.
Re: std.math performance (SSE vs. real)
On 7/2/2014 2:28 PM, Iain Buclaw via Digitalmars-d wrote: On 2 July 2014 19:58, via Digitalmars-d digitalmars-d@puremagic.com wrote: I don't really understand the reasoning here. Is D Intel x86 specific? Yes it is, more than you might realise. I've been spending the last 4 years breaking it to be platform agnostic. :o) I think you're conflating dmd with D. And IEEE 754 is a standard.
Re: std.math performance (SSE vs. real)
On Wed, Jul 02, 2014 at 05:03:47PM -0700, Walter Bright via Digitalmars-d wrote: [...] D is a systems programming language. That means it should have access to the hardware supported types. Portability is not the only goal - especially if that means least common denominator. People pay money for more powerful chips, and they'll want to use them. What should we do in the case of hardware that offers strange hardware types, like a hypothetical 48-bit floating point type? Should D offer a built-in type for that purpose, even if it only exists on a single chip that's used by 0.01% of the community? Not only that, a marquee feature of D is interoperability with C. We'd need an AWFULLY good reason to throw that under the bus. I'm not sure I understand how removing support 80-bit floats hurts interoperability with C? I thought none of the standard C float types map to the x87 80-bit float? (I'm not opposed to keeping real as 80-bit on x87, but I just don't understand what this has to do with C interoperability.) T -- In order to understand recursion you must first understand recursion.
Re: std.math performance (SSE vs. real)
On Thursday, 3 July 2014 at 01:13:13 UTC, H. S. Teoh via Digitalmars-d wrote: I'm not sure I understand how removing support 80-bit floats hurts interoperability with C? I thought none of the standard C float types map to the x87 80-bit float? The C spec never says anything specific about representation because it's meant to target anything, but the x86 and AMD64 ABIs basically say that long double is 80-bit for calculations. The x86 spec says that the type is stored in 96 bits though, and the AMD64 spec says they're stored in 128 bits for alignment purposes. I'm still unclear whether we're aiming for C interoperability or hardware support though, based on Walter's remark about SPARC and PPC. There, 'long double' is represented differently but is not backed by specialized hardware, so I'm guessing D would make 'real' 64-bits on these platforms and break compatibility with C. So... I guess we really do need a special alias for C compatibility, and this can map to whatever intrinsic type the applicable compiler supports for that platform.
Re: std.math performance (SSE vs. real)
On Monday, 30 June 2014 at 22:58:48 UTC, Walter Bright wrote: Wow. Fortunately, there's a switch http://publib.boulder.ibm.com/infocenter/cellcomp/v101v121/index.jsp?topic=/com.ibm.xlcpp101.cell.doc/proguide/spu_sp_diffs.html so it'll work correctly. That's the same link I provided, but I presume the compiler switch kills performance? You have the same with ARM processors. NEON (SIMD) instructions are not IEEE754 compliant. VPF is almost compliant, but does not support subnormal numbers and flush them to zero. Which can be a disaster… So basically, floating point is not portable unless you give up performance or check all expressions with worst case analysis based on deficiencies on all current platforms.
Re: std.math performance (SSE vs. real)
On 1 July 2014 06:34, dennis luehring via Digitalmars-d digitalmars-d@puremagic.com wrote: Am 01.07.2014 00:18, schrieb Andrei Alexandrescu: On 6/30/14, 2:20 AM, Don wrote: For me, a stronger argument is that you can get *higher* precision using doubles, in many cases. The reason is that FMA gives you an intermediate value with 128 bits of precision; it's available in SIMD but not on x87. So, if we want to use the highest precision supported by the hardware, that does *not* mean we should always use 80 bits. I've experienced this in CTFE, where the calculations are currently done in 80 bits, I've seen cases where the 64-bit runtime results were more accurate, because of those 128 bit FMA temporaries. 80 bits are not enough!! Interesting. Maybe we should follow a simple principle - define overloads and intrinsic operations such that real is only used if (a) requested explicitly (b) it brings about an actual advantage. gcc seems to use GMP for (all) its compiletime calculations - is this for cross-compile unification of calculation results or just for better result at all - or both? More cross-compilation where the host has less precision than the target. But at the same time they wouldn't use GMP if it didn't produce accurate results. :)
Re: std.math performance (SSE vs. real)
dennis luehring wrote in message news:loth9o$2arl$1...@digitalmars.com... gcc seems to use GMP for (all) its compiletime calculations - is this for cross-compile unification of calculation results or just for better result at all - or both? To make the gcc build process more complicated.
Re: std.math performance (SSE vs. real)
On Monday, 30 June 2014 at 16:54:17 UTC, Walter Bright wrote: On 6/30/2014 12:20 AM, Don wrote: What I think is highly likely is that it will only have legacy support, with such awful performance that it never makes sense to use them. For example, the speed of 80-bit and 64-bit calculations in x87 used to be identical. But on recent Intel CPUs, the 80-bit operations run at half the speed of the 64 bit operations. They are already partially microcoded. For me, a stronger argument is that you can get *higher* precision using doubles, in many cases. The reason is that FMA gives you an intermediate value with 128 bits of precision; it's available in SIMD but not on x87. So, if we want to use the highest precision supported by the hardware, that does *not* mean we should always use 80 bits. I've experienced this in CTFE, where the calculations are currently done in 80 bits, I've seen cases where the 64-bit runtime results were more accurate, because of those 128 bit FMA temporaries. 80 bits are not enough!! I did not know this. It certainly adds another layer of nuance - as the higher level of precision will only apply as long as one can keep the value in a register. Yes, it's complicated. The interesting thing is that there are no 128 bit registers. The temporaries exist only while the FMA operation is in progress. You cannot even preserve them between consecutive FMA operations. An important consequence is that allowing intermediate calculations to be performed at higher precision than the operands, is crucial, and applies outside of x86. This is something we've got right. But it's not possible to say that the intermediate calculations are done at the precision of 'real'. This is the semantics which I think we currently have wrong. Our model is too simplistic. On modern x86, calculations on float operands may have intermediate calculations done at only 32 bits (if using straight SSE), 80 bits (if using x87), or 64 bits (if using float FMA). And for double operands, they may be 64 bits, 80 bits, or 128 bits. Yet, in the FMA case, non-FMA operations will be performed at lower precision. It's entirely possible for all three intermediate precisions to be active at the same time! I'm not sure that we need to change anything WRT code generation. But I think our style recommendations aren't quite right. And we have at least one missing primitive operation (discard all excess precision).
Re: std.math performance (SSE vs. real)
On 6/30/2014 11:58 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Monday, 30 June 2014 at 22:58:48 UTC, Walter Bright wrote: Wow. Fortunately, there's a switch http://publib.boulder.ibm.com/infocenter/cellcomp/v101v121/index.jsp?topic=/com.ibm.xlcpp101.cell.doc/proguide/spu_sp_diffs.html so it'll work correctly. That's the same link I provided, but I presume the compiler switch kills performance? Click on compiling for strict IEEE conformance You have the same with ARM processors. NEON (SIMD) instructions are not IEEE754 compliant. VPF is almost compliant, but does not support subnormal numbers and flush them to zero. Which can be a disaster… It wouldn't be any different if the D spec says floating point is, ya know, whatevah. You can't fix stuff like this in the spec. So basically, floating point is not portable unless you give up performance or check all expressions with worst case analysis based on deficiencies on all current platforms. As I've posted before, nobody's FP code is going to work on such platforms out of the box even if the spec is accommodating for it. The whole point of IEEE 754 is to make portable FP code possible. Besides, Java and Javascript, for example, both require IEEE conformance.
Re: std.math performance (SSE vs. real)
On 7/1/2014 3:26 AM, Don wrote: Yes, it's complicated. The interesting thing is that there are no 128 bit registers. The temporaries exist only while the FMA operation is in progress. You cannot even preserve them between consecutive FMA operations. An important consequence is that allowing intermediate calculations to be performed at higher precision than the operands, is crucial, and applies outside of x86. This is something we've got right. But it's not possible to say that the intermediate calculations are done at the precision of 'real'. This is the semantics which I think we currently have wrong. Our model is too simplistic. On modern x86, calculations on float operands may have intermediate calculations done at only 32 bits (if using straight SSE), 80 bits (if using x87), or 64 bits (if using float FMA). And for double operands, they may be 64 bits, 80 bits, or 128 bits. Yet, in the FMA case, non-FMA operations will be performed at lower precision. It's entirely possible for all three intermediate precisions to be active at the same time! I'm not sure that we need to change anything WRT code generation. But I think our style recommendations aren't quite right. And we have at least one missing primitive operation (discard all excess precision). What do you recommend?
Re: std.math performance (SSE vs. real)
On Tuesday, 1 July 2014 at 16:58:55 UTC, Walter Bright wrote: Click on compiling for strict IEEE conformance It also states that compliance affect performance. not IEEE754 compliant. VPF is almost compliant, but does not support subnormal numbers and flush them to zero. Which can be a disaster… It wouldn't be any different if the D spec says floating point is, ya know, whatevah. You can't fix stuff like this in the spec. Well, the difference is that you can make VPF mostly compliant, but that means you trap subnormal numbers and fix it in software. Which affects performance. If the specs require IEEE754 compliance then you default to software emulation and have to turn it off through compiler switches. Here is another example: the parallella Coprocessor from Adapteva: «The CPU is compatible with the IEEE-754 single-precision format, with the following exceptions: - No support for inexact flags. - NAN inputs generate an invalid exception and return a quiet NAN. When one or both of the inputs are NANs, the sign bit of the operation is set as an XOR of the signs of the input sign bits. - Denormal operands are flushed to zero when input to a computation unit and do not generate an underflow exception. Any denormal or underflow result from an arithmetic operation is flushed to zero and an underflow exception is generated. - Round-to-±infinity is not supported.» Besides, Java and Javascript, for example, both require IEEE conformance. But they aren't system level programming languages… and we probably cannot expect future many-core processors or transputer-like processors to waste die space in order to conform. So sure you can specify the IEEE-754 spec and just make D run at full rate on typical CISC CPUs, but the alternative is to constrain the promise of compliance to what is typical for efficient CPUs. Then have a -strict flag for the few applications that are scientific in nature. That would be more in line with system level programming.
Re: std.math performance (SSE vs. real)
On 6/29/2014 9:38 PM, Manu via Digitalmars-d wrote: It's news to me that x86, x86-64, etc., are deprecated, despite being used to run pretty much all desktops and laptops and even servers. The 80 bit reals are also part of the C ABI for Linux, OSX, and FreeBSD, 32 and 64 bit. x86_64 and x86 are different architectures, and they have very different ABI's. Nobody is manufacturing x86 (exclusive) cpu's. Current x86_64 cpu's maintain a backwards compatibility mode, but that's not a part of the x86-64 spec, and may go away when x86_64 is deemed sufficiently pervasive and x86 sufficiently redundant. It's still part of the C ABI for both 32 and 64 bit code. Correct, so they are deliberately treated separately. I argued for strong separation between simd and float, and you agreed. floats doubles are implemented using SIMD instructions. Since they are part of the 64 bit C ABI, that would seem to be in the category of nevah hoppen. Not in windows. Correct. You say they are in linux? I don't know. Since you don't believe me, I recommend looking it up. The document is entitled System V Application Binary Interface AMD64 Architecture Processor Supplement Furthermore, just try using long double on Linux, and disassemble the resulting code. How do you distinguish x87 double and xmm double in C? You don't. It's a compiler implementation issue. The only way I know to access x87 is with inline asm. I suggest using long double on Linux and look at the compiler output. You don't have to believe me - use gcc or clang. Huh? I think you misunderstood my point. I'm saying that fpu/simd units are distinct, and they are distanced by the type system in order to respect that separation. I think that's not correct. There's nothing in the C Standard that says you have to implement float semantics with any particular FPU, nor does the C type system distinguish FPUs.
Re: std.math performance (SSE vs. real)
On Monday, 30 June 2014 at 04:15:46 UTC, Walter Bright wrote: On 6/29/2014 8:22 PM, Manu via Digitalmars-d wrote: Well, here's the thing then. Consider that 'real' is only actually supported on only a single (long deprecated!) architecture. In x64's case, it is deprecated for over a decade now, and may be removed from the hardware at some unknown time. The moment that x64 processors decide to stop supporting 32bit code, the x87 will go away, and those opcodes will likely be emulated or microcoded. Interacting real-float/double means register swapping through memory. It should be treated the same as float-simd; they are distinct (on most arch's). Since they are part of the 64 bit C ABI, that would seem to be in the category of nevah hoppen. What I think is highly likely is that it will only have legacy support, with such awful performance that it never makes sense to use them. For example, the speed of 80-bit and 64-bit calculations in x87 used to be identical. But on recent Intel CPUs, the 80-bit operations run at half the speed of the 64 bit operations. They are already partially microcoded. For me, a stronger argument is that you can get *higher* precision using doubles, in many cases. The reason is that FMA gives you an intermediate value with 128 bits of precision; it's available in SIMD but not on x87. So, if we want to use the highest precision supported by the hardware, that does *not* mean we should always use 80 bits. I've experienced this in CTFE, where the calculations are currently done in 80 bits, I've seen cases where the 64-bit runtime results were more accurate, because of those 128 bit FMA temporaries. 80 bits are not enough!!
Re: std.math performance (SSE vs. real)
On Monday, 30 June 2014 at 06:21:49 UTC, Walter Bright wrote: When precision is an issue we always choose a software solution. This has been my experience in both geophysics and medical device development. It is cheaper, faster (dev. time), and better tested than anything we would develop within a release time frame. But D real is a winner IMO. At my last workplace we ported some geophysics C++ apps to D for fun. The apps required more precision than double could offer and relied on GMP/MPFR. It was a nice surprise when we found the extra bits in D's real were enough for some of these apps to be correct without GMP/MPFR and gave a real performance boost (pun intended!). We targeted x86/x86_64 desktops and clusters running linux (windows and MAC on desktops as well). We did not consider the lack of IBM 360 support to be an issue when porting to D :-P Cheers, ed
Re: std.math performance (SSE vs. real)
On Monday, 30 June 2014 at 07:21:00 UTC, Don wrote: On Monday, 30 June 2014 at 04:15:46 UTC, Walter Bright wrote: On 6/29/2014 8:22 PM, Manu via Digitalmars-d wrote: Well, here's the thing then. Consider that 'real' is only actually supported on only a single (long deprecated!) architecture. In x64's case, it is deprecated for over a decade now, and may be removed from the hardware at some unknown time. The moment that x64 processors decide to stop supporting 32bit code, the x87 will go away, and those opcodes will likely be emulated or microcoded. Interacting real-float/double means register swapping through memory. It should be treated the same as float-simd; they are distinct (on most arch's). Since they are part of the 64 bit C ABI, that would seem to be in the category of nevah hoppen. What I think is highly likely is that it will only have legacy support, with such awful performance that it never makes sense to use them. For example, the speed of 80-bit and 64-bit calculations in x87 used to be identical. But on recent Intel CPUs, the 80-bit operations run at half the speed of the 64 bit operations. They are already partially microcoded. For me, a stronger argument is that you can get *higher* precision using doubles, in many cases. The reason is that FMA gives you an intermediate value with 128 bits of precision; it's available in SIMD but not on x87. So, if we want to use the highest precision supported by the hardware, that does *not* mean we should always use 80 bits. I've experienced this in CTFE, where the calculations are currently done in 80 bits, I've seen cases where the 64-bit runtime results were more accurate, because of those 128 bit FMA temporaries. 80 bits are not enough!! This is correct and we use this now for some time critical code that requires high precision. But anything non-time critical (~80%-85% of our code) we simply use a software solution when precision becomes an issue. It is here that I think the extra bits in D real can be enough to get a performance gain. But I won't argue with you think I'm wrong. I'm only basing this on anecdotal evidence of what I saw from 5-6 apps ported from C++ to D :-) Cheers, ed
Re: std.math performance (SSE vs. real)
On Sunday, 29 June 2014 at 22:49:44 UTC, Walter Bright wrote: I guess we just hope that all future hardware is IEEE754 compliant. I'm not concerned about it. No CPU maker in their right head would do something different. AFAIK they break compliance all the time.
Re: std.math performance (SSE vs. real)
On Sunday, 29 June 2014 at 18:13:59 UTC, Russel Winder via Digitalmars-d wrote: On Sun, 2014-06-29 at 07:59 -0700, Andrei Alexandrescu via Digitalmars-d wrote: […] A friend who works at a hedge fund (after making the rounds to the NYC large financial companies) told me that's a myth. Any nontrivial calculation involving money (interest, fixed income, derivatives, ...) needs floating point. He never needed more than double. Very definitely so. Fixed point or integer arithmetic for simple household finance fair enough, but for finance house calculations you generally need 22+ significant denary digits to meet with compliance requirements. Many people seem to have the bizarre idea that floating point is less accurate than integer arithmetic. As if storing a value into a double makes it instantly fuzzy, or something. In fact, providing that the the precision is large enough, every operation that is exact in integers, is exact in floating point as well. And if you perform a division using integers, you've silently lost precision. So I'm not sure what benefit you'd gain by eschewing floating point.
Re: std.math performance (SSE vs. real)
On Monday, 30 June 2014 at 11:57:04 UTC, Don wrote: And if you perform a division using integers, you've silently lost precision. 2 ints of arbitrary length = rational numbers = no loss of precision for divs. CPU vendors make arbitrary decisions about FP and break compliance with no remorse for single precision float vector operations in order to reduce die size / increase throughput. That includes not having NaN/Inf, reducing mantissa precision for some operations, etc. FP is not portable out-of-the-box. I think the main advantage of integers is that you control the precision and can repeat the calculation with the same result. It is easier to avoid stability issues with integers too. And it is portable.
Re: std.math performance (SSE vs. real)
On Sun, Jun 29, 2014 at 11:33:20PM +0100, Iain Buclaw via Digitalmars-d wrote: On 29 June 2014 23:20, H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sun, Jun 29, 2014 at 08:54:49AM +0100, Iain Buclaw via Digitalmars-d wrote: On 29 Jun 2014 05:48, H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sat, Jun 28, 2014 at 08:41:24PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 6/28/14, 6:02 PM, Tofu Ninja wrote: [...] I think this thread needs to refocus on the main point, getting math overloads for float and double and how to mitigate any problems that might arise from that. Yes please. -- Andrei Let's see the PR! I've already raised one (already linked in this thread). Are you talking about #2274? Interesting that your implementation is basically identical to my own idea for fixing std.math -- using unions instead of pointer casting. Not really. The biggest speed up was from adding float+double overloads for floor, ceil, isNaN and isInfinity. Firstly, the use of a union itself didn't make much of a dent in the speed up. Removing the slow array copy operation did though. Secondly, unions are required for this particular function (floor) because we need to set bits through type-punning, it just wouldn't work casting to a pointer. [...] I wasn't referring to the speedup (though that is certainly nice), I was talking about making things CTFE-able. What's the status of repainting unions in CTFE? Is there a PR for that yet, or do we need to implement one? T -- People tell me that I'm skeptical, but I don't believe it.
Re: std.math performance (SSE vs. real)
Am 30.06.2014 18:30, schrieb dennis luehring:
Am 30.06.2014 08:21, schrieb Walter Bright:
The only way I know to access x87 is with inline asm.
I suggest using long double on Linux and look at the compiler output. You
don't have to believe me - use gcc or clang.
gcc.godbolt.org clang 3.4.1 -O3
better this
int main(int argc, char** argv)
{
return argc * 12345.6789L;
}
.LCPI0_0:
# x86_fp80 12345.67889996
.quad -4546745350290602879
.short 16396
.zero 6
main: # @main
movl%edi, -8(%rsp)
fldt.LCPI0_0(%rip)
fimull -8(%rsp)
fnstcw -10(%rsp)
movw-10(%rsp), %ax
movw$3199, -10(%rsp)# imm = 0xC7F
fldcw -10(%rsp)
movw%ax, -10(%rsp)
fistpl -4(%rsp)
fldcw -10(%rsp)
movl-4(%rsp), %eax
ret
