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)
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)
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 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 5 July 2014 16:13, via Digitalmars-d 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 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)
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: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)
On 5 July 2014 15:20, via Digitalmars-d 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 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 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 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 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 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 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 Thu, 3 Jul 2014 14:01:23 -0700 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. 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 7/4/2014 1:41 PM, "Ola Fosheim Grøstad" " 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 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:13 PM, "Ola Fosheim Grøstad" " 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 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 12:07 PM, "Ola Fosheim Grøstad" " 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 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 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 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 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 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 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 5:48 AM, "Ola Fosheim Grøstad" " 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 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 4 July 2014 17:31, Daniel Murphy via Digitalmars-d 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)
"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 14:01, Daniel Murphy via Digitalmars-d wrote: > > "Iain Buclaw via Digitalmars-d" 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.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)
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)
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)
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)
"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 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)
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 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 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 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 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 7/3/2014 2:43 PM, "Ola Fosheim Grøstad" " 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 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" > >" 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 3 July 2014 22:43, 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" >> " 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 Wednesday, 2 July 2014 at 21:45:41 UTC, Walter Bright wrote: On 7/2/2014 5:24 AM, "Ola Fosheim Grøstad" " 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 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 Thu, 03 Jul 2014 12:45:17 -0700 Walter Bright via Digitalmars-d 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 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 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 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 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 3 July 2014 14:51, Joseph Rushton Wakeling via Digitalmars-d 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 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 11:49, Jonathan M Davis via Digitalmars-d wrote: > On Wed, 02 Jul 2014 23:56:21 -0700 > Walter Bright via Digitalmars-d 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 Wed, 02 Jul 2014 23:56:21 -0700 Walter Bright via Digitalmars-d 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 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 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 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 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 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 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 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 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 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 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 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 7/2/2014 2:28 PM, Iain Buclaw via Digitalmars-d wrote: On 2 July 2014 19:58, via Digitalmars-d 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 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 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 5:24 AM, "Ola Fosheim Grøstad" " wrote: D is not even production ready, Of course it is.
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 2 July 2014 21:37, Walter Bright via Digitalmars-d 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 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 19:58, via Digitalmars-d 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 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 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 2 July 2014 12:42, via Digitalmars-d 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 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 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 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 2 July 2014 09:53, Don via Digitalmars-d 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 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 1 July 2014 20:36, via Digitalmars-d 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 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 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 6/30/2014 11:58 PM, "Ola Fosheim Grøstad" " 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 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)
"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 1 July 2014 06:34, dennis luehring via Digitalmars-d 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)
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)
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?
Re: std.math performance (SSE vs. real)
On Tue, Jul 01, 2014 at 01:21:11AM +, Chris Cain via Digitalmars-d wrote: > On Monday, 30 June 2014 at 21:51:22 UTC, H. S. Teoh via Digitalmars-d wrote: > >How do you implement 80-bit reals in the library? > > Is it a legitimate problem to do so? My feeling is that it should be > possible if it's possible to implement it in C or asm since it's > possible to do everything in D that is possible to do in C or asm. It will be a pain, because you will need asm blocks to implement x87 instructions. And you won't be able to simulate optimizations that the compiler can -- like common subexpression factoring, eliminating redundant loads, etc.. Those are precisely the kind of things that you need compiler support for, in order to have acceptable performance. (Well, you *could* in theory implement these optimizations using CTFE to produce asm string mixins, but you'd have to use string DSLs instead of language-level expressions in order for this to work. Or you'd have to use expression templates, which will become an unmaintainable mess. Plus you'd be reinventing much of what the compiler already does for you -- register allocation, codegen, etc.. Basically, all that work just to move reals outside the compiler seems to be misdirected effort to me.) T -- If you think you are too small to make a difference, try sleeping in a closed room with a mosquito. -- Jan van Steenbergen
Re: std.math performance (SSE vs. real)
On Monday, 30 June 2014 at 21:51:22 UTC, H. S. Teoh via Digitalmars-d wrote: How do you implement 80-bit reals in the library? Is it a legitimate problem to do so? My feeling is that it should be possible if it's possible to implement it in C or asm since it's possible to do everything in D that is possible to do in C or asm.
Re: std.math performance (SSE vs. real)
On 6/30/2014 3:14 PM, "Ola Fosheim Grøstad" " wrote: On Monday, 30 June 2014 at 16:54:55 UTC, Walter Bright wrote: On 6/30/2014 4:25 AM, "Ola Fosheim Grøstad" " wrote: AFAIK they break compliance all the time. Examples, please. Cell: http://publib.boulder.ibm.com/infocenter/cellcomp/v101v121/index.jsp?topic=/com.ibm.xlcpp101.cell.doc/proguide/spu_sp_diffs.html 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. Intel: http://www.velocityreviews.com/threads/intel-fp-h-w-non-compliance-to-ieee754.746517/ That one looks like a bug.
Re: std.math performance (SSE vs. real)
On 6/30/2014 3:43 PM, H. S. Teoh via Digitalmars-d wrote: Iain's PR to provide overloads of std.math functions for float/double has already been merged, so all that remains is for float literals to default to double unless suffixed with L, They already do. or contain too many digits to accurately represent in double. This won't work predictably. Heck, 0.3 is not accurately representable as a double.
Re: std.math performance (SSE vs. real)
On Monday, 30 June 2014 at 22:44:44 UTC, H. S. Teoh via Digitalmars-d wrote: Iain's PR to provide overloads of std.math functions for float/double has already been merged, so all that remains […] Plus all the other functions in std.math, plus a way to provide efficient implementations depending on the target instruction set (compiler intrinsics). David
Re: std.math performance (SSE vs. real)
On Mon, Jun 30, 2014 at 05:18:43PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: > 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. > > I.e. most of the time not using real in user code means it's never > real throughout. [...] Iain's PR to provide overloads of std.math functions for float/double has already been merged, so all that remains is for float literals to default to double unless suffixed with L, or contain too many digits to accurately represent in double. T -- Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.
Re: std.math performance (SSE vs. real)
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. I.e. most of the time not using real in user code means it's never real throughout. Andrei
Re: std.math performance (SSE vs. real)
On Monday, 30 June 2014 at 16:54:55 UTC, Walter Bright wrote: On 6/30/2014 4:25 AM, "Ola Fosheim Grøstad" " wrote: AFAIK they break compliance all the time. Examples, please. Cell: http://publib.boulder.ibm.com/infocenter/cellcomp/v101v121/index.jsp?topic=/com.ibm.xlcpp101.cell.doc/proguide/spu_sp_diffs.html Intel: http://www.velocityreviews.com/threads/intel-fp-h-w-non-compliance-to-ieee754.746517/ ARM Neon vs VPF… etc.