Jump to page: 1 2
Thread overview
[dmd-internals] math intrinsics
Apr 02, 2011
Brad Roberts
Apr 02, 2011
Walter Bright
Apr 02, 2011
Don Clugston
Apr 02, 2011
David Simcha
Apr 02, 2011
Don Clugston
Apr 02, 2011
Brad Roberts
Apr 02, 2011
Don Clugston
Apr 04, 2011
Sean Kelly
Apr 05, 2011
Brad Roberts
Apr 05, 2011
Sean Kelly
April 01, 2011
Any objection to moving the math intrinsics from phobos std/math.d to druntime core/math.d similar to the bitops?  I'll be happy to whip up the pull requests.
April 02, 2011
worksforme. Sean, Don?

Andrei

On 4/2/11 1:06 AM, Brad Roberts wrote:
> Any objection to moving the math intrinsics from phobos std/math.d to druntime core/math.d similar to the bitops?  I'll
> be happy to whip up the pull requests.
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
April 01, 2011
Rock on.

On 4/1/2011 11:08 PM, Andrei Alexandrescu wrote:
> worksforme. Sean, Don?
>
> Andrei
>
> On 4/2/11 1:06 AM, Brad Roberts wrote:
>> Any objection to moving the math intrinsics from phobos std/math.d to
>> druntime core/math.d similar to the bitops?  I'll
>> be happy to whip up the pull requests.
April 02, 2011
Great, if everything still works.

On 2 April 2011 08:06, Brad Roberts <braddr at puremagic.com> wrote:
> Any objection to moving the math intrinsics from phobos std/math.d to druntime core/math.d similar to the bitops? ?I'll
> be happy to whip up the pull requests.
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
April 02, 2011
As long as core.math would be publicly imported by std.math instead of being yet another import to remember, I'm on board.

On Sat, Apr 2, 2011 at 4:24 AM, Don Clugston <dclugston at googlemail.com>wrote:

> Great, if everything still works.
>
> On 2 April 2011 08:06, Brad Roberts <braddr at puremagic.com> wrote:
> > Any objection to moving the math intrinsics from phobos std/math.d to
> druntime core/math.d similar to the bitops?  I'll
> > be happy to whip up the pull requests.
> > _______________________________________________
> > dmd-internals mailing list
> > dmd-internals at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/dmd-internals
> >
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20110402/699e5b69/attachment-0001.html>
April 02, 2011
There have been linking problems (at least with optlink) when two modules have the same filename. I'm a bit wary of the name core.math. Now that I think about it a bit more, I've changed my mind. I don't think it's a good idea. The fact that (say) sin is an intrinsic is DMD-specific. It won't be an intrinsic on many other compilers.

On 2 April 2011 16:13, David Simcha <dsimcha at gmail.com> wrote:
> As long as core.math would be publicly imported by std.math instead of being yet another import to remember, I'm on board.
>
> On Sat, Apr 2, 2011 at 4:24 AM, Don Clugston <dclugston at googlemail.com> wrote:
>>
>> Great, if everything still works.
>>
>> On 2 April 2011 08:06, Brad Roberts <braddr at puremagic.com> wrote:
>> > Any objection to moving the math intrinsics from phobos std/math.d to
>> > druntime core/math.d similar to the bitops? ?I'll
>> > be happy to whip up the pull requests.
>> > _______________________________________________
>> > dmd-internals mailing list
>> > dmd-internals at puremagic.com
>> > http://lists.puremagic.com/mailman/listinfo/dmd-internals
>> >
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
April 02, 2011
Yes, std.math publicly imports core.math in the pull requests I submitted last night.

Can you point to concrete examples / bug reports for the optlink issue?

Intrinsics aren't compiler specific, they tend to be platform specific.  But even when not done as a builtin, they can just as easily be written a d code or asm in the runtime.

For what it's worth, I created the pull requests for all three packages and I've tested it on both linux32 and win32 and everything passes just fine.

Later,
Brad

On 4/2/2011 8:42 AM, Don Clugston wrote:
> There have been linking problems (at least with optlink) when two modules have the same filename. I'm a bit wary of the name core.math. Now that I think about it a bit more, I've changed my mind. I don't think it's a good idea. The fact that (say) sin is an intrinsic is DMD-specific. It won't be an intrinsic on many other compilers.
> 
> On 2 April 2011 16:13, David Simcha <dsimcha at gmail.com> wrote:
>> As long as core.math would be publicly imported by std.math instead of being yet another import to remember, I'm on board.
>>
>> On Sat, Apr 2, 2011 at 4:24 AM, Don Clugston <dclugston at googlemail.com> wrote:
>>>
>>> Great, if everything still works.
>>>
>>> On 2 April 2011 08:06, Brad Roberts <braddr at puremagic.com> wrote:
>>>> Any objection to moving the math intrinsics from phobos std/math.d to
>>>> druntime core/math.d similar to the bitops?  I'll
>>>> be happy to whip up the pull requests.
>>>> _______________________________________________

April 02, 2011
On 2 April 2011 21:35, Brad Roberts <braddr at puremagic.com> wrote:
> Yes, std.math publicly imports core.math in the pull requests I submitted last night.
>
> Can you point to concrete examples / bug reports for the optlink issue?

No, but I know Tango changed the names of all such modules because of it.

> Intrinsics aren't compiler specific, they tend to be platform specific. ?But even when not done as a builtin, they can just as easily be written a d code or asm in the runtime.

No, that's not correct. It's particularly untrue for the math functions. DMD does the trig functions as intrinsics using the x87 instructions. But they are slow, and not accurate in some circumstances. It's arguably better to use SSE2 (especially on 64 bits). Try sin(2^^65)   --- the intrinsic returns 2^^65, ie absolute garbage!

If instead, they are implemented with d code or asm in the runtime, you end up with code duplication. If the functions are not intrinsics, they will be implemented with std.math.poly.

Note that even the intrinsics for GDC are different to the ones for
DMD (I think exp() is an intrinsic).

The question I have, is, what does this extra complexity and code
duplication buy you?
(If there was a single module, core.intrinsic, which included all
intrinsics which reduce to a single machine instruction, I think it
would be OK -- that is clearly CPU specific; and you could even test
for existence of particular intrinsics using reflection. This would
even allow the use of (for example) the x87 sin() function, even if
std.math implemented sin() in a slower but more accurate way).
But I think putting all math intrinsics in a module is something I'm
sure we'd later regret.


>
> For what it's worth, I created the pull requests for all three packages and I've tested it on both linux32 and win32 and everything passes just fine.
>
> Later,
> Brad
>
> On 4/2/2011 8:42 AM, Don Clugston wrote:
>> There have been linking problems (at least with optlink) when two modules have the same filename. I'm a bit wary of the name core.math. Now that I think about it a bit more, I've changed my mind. I don't think it's a good idea. The fact that (say) sin is an intrinsic is DMD-specific. It won't be an intrinsic on many other compilers.
>>
>> On 2 April 2011 16:13, David Simcha <dsimcha at gmail.com> wrote:
>>> As long as core.math would be publicly imported by std.math instead of being yet another import to remember, I'm on board.
>>>
>>> On Sat, Apr 2, 2011 at 4:24 AM, Don Clugston <dclugston at googlemail.com> wrote:
>>>>
>>>> Great, if everything still works.
>>>>
>>>> On 2 April 2011 08:06, Brad Roberts <braddr at puremagic.com> wrote:
>>>>> Any objection to moving the math intrinsics from phobos std/math.d to
>>>>> druntime core/math.d similar to the bitops? ?I'll
>>>>> be happy to whip up the pull requests.
>>>>> _______________________________________________
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
April 04, 2011
On Apr 1, 2011, at 11:06 PM, Brad Roberts wrote:

> Any objection to moving the math intrinsics from phobos std/math.d to druntime core/math.d similar to the bitops?  I'll be happy to whip up the pull requests.

I don't know that I want stuff in druntime simply because it can be made intrinsic--that's largely a QOI issue for compilers.  If there's a solid justification for a core.math module, that's a different story.  One easy litmus test I use for what belongs in druntime is if druntime itself needs the module to implement some other functionality.  So far, I've seen little need for std-defined math functions in druntime.
April 04, 2011
My litmus test is essentially:

1) Is it something the compiler emits code to call.  That covers pretty much all of _d_*.

2) Is it something that the compiler expects to be named something specific.  The intrinsics fall into this camp.  I don't think it that the compiler should look in std.intrinsic, std.math, tango.intrinsic, etc.

3) Is it something that is common across standard libraries, for example both Phobos and Tango, and should be shared.  I think intrinsics fall into this camp also.

That said, these are just guidelines for how I think about it.  There are no absolutes and I'm not dead set on having the math intrinsics in the runtime.  I saw that walter merged in the dmd parts of my change.  I don't intend on merging the other two parts in unless there's general agreement that it's the right thing to do.  Don's objections are reasonable for the parts that aren't direct translations to a single asm instruction.  I need to go back and re-read his email and look under the covers at what dmd is doing.  My gut says they should still move, but it's as obvious.

For what it's worth, I still think some of the lowest level utf primitive functions belong in and should be exposed by the runtime.  Right now they're duplicated between rt.mumble and std.mumble.

Later,
Brad

On Mon, 4 Apr 2011, Sean Kelly wrote:

> On Apr 1, 2011, at 11:06 PM, Brad Roberts wrote:
> 
> > Any objection to moving the math intrinsics from phobos std/math.d to druntime core/math.d similar to the bitops?  I'll be happy to whip up the pull requests.
> 
> I don't know that I want stuff in druntime simply because it can be made intrinsic--that's largely a QOI issue for compilers.  If there's a solid justification for a core.math module, that's a different story.  One easy litmus test I use for what belongs in druntime is if druntime itself needs the module to implement some other functionality.  So far, I've seen little need for std-defined math functions in druntime. _______________________________________________ dmd-internals mailing list dmd-internals at puremagic.com http://lists.puremagic.com/mailman/listinfo/dmd-internals
> 
« First   ‹ Prev
1 2