On 2013-12-22 22:30, Iain Buclaw wrote:

> While useful the ability to write inline assembler functions, DMD
> can't inline these around the place. So you get all the benefits of
> being able to shortcut the fastest route to do X, but with the
> slowdown of 25% because there's a big elephant in the room.

I'm not talking about any specific compiler. I also wrote this post[1], which is more in line of with what GDC and LDC provides.

[1] http://forum.dlang.org/thread/mailman.28.1387438018.2938.digitalmars-d@puremagic.com?page=3#post-l943eg:24170f:241:40digitalmars.com

-- 
/Jacob Carlborg

Iain Buclaw:

> For inline assembly, making dmd work better how?

I meant making dmd better in general. Faster floating point, more
optimization tricks, etc.


> Not possible without some sort of translation map, which would be target
> specific, so not suitable for GDC, and language specific so not suitable for GCC either.
>
> Also, falls under category of x86-centric below.

Did you express such problems during the design phase of that
recent language feature?

Bye,
bearophile

On Sunday, 22 December 2013 at 19:49:21 UTC, Joseph Rushton Wakeling wrote:
> On 20/12/13 02:40, Francesco Cattoglio wrote:
>> I don't know, I feel like I would be more useful if I only sticked with working
>> on the standard library when needed and writing software that others might find
>> interesting (I'm planning on "resurrecting" SciD btw)
>
> Nice to know -- anything in particular you are keen to work on there?

No real battleplan other than turning it into a DUB package, then I guess I will move from there. But first, I need to analyze and understand the 2 codebases: the Kyllingstad one and the cristicbz fork. I'd like to understand if there's any way to reconciliate them and/or which one is the "best" to start working on.
After that I'll probably look into linear algebra. But this will start next year. I need to properly learn D with this project (I only played with it untill now, no serious projects on the record).

Help is welcome, ofc. Kyllingstad himself wanted SciD to be a community effort.

On 23 December 2013 11:05, bearophile <bearophileHUGS@lycos.com> wrote:
> Iain Buclaw:
>
>
>> For inline assembly, making dmd work better how?
>
>
> I meant making dmd better in general. Faster floating point, more optimization tricks, etc.
>
>
>
>> Not possible without some sort of translation map, which would be target specific, so not suitable for GDC, and language specific so not suitable for GCC either.
>>
>> Also, falls under category of x86-centric below.
>
>
> Did you express such problems during the design phase of that recent language feature?
>

I'll answer that with a question. Did you really think that __simd went through a design phase? :-)

Iain Buclaw:

Did you really think that __simd went through a design phase? :-)

I understand. So there is still a problem bigger than __simd.

Bye,
bearophile

On 23/12/13 12:57, Francesco Cattoglio wrote:
> No real battleplan other than turning it into a DUB package, then I guess I will
> move from there. But first, I need to analyze and understand the 2 codebases:
> the Kyllingstad one and the cristicbz fork. I'd like to understand if there's
> any way to reconciliate them and/or which one is the "best" to start working on.

Sounds good to me.  By the way, I think Cristi was considering targeting the linear algebra work towards Phobos -- you might like to consider if some parts of SciD could be reworked as standard library features, although obviously you have greater freedom to extend and experiment in an independent library.

> After that I'll probably look into linear algebra. But this will start next
> year. I need to properly learn D with this project (I only played with it untill
> now, no serious projects on the record).

You are going to have a lot of fun.  Getting one's teeth seriously into D is a very pleasurable experience.

(Ways to know the internet has jaded you no. 43995123: understanding how 4chan users will read the previous sentence....:-)

> Help is welcome, ofc. Kyllingstad himself wanted SciD to be a community effort.

I'm interested, but it's always about time commitments.  But if you can come up with a TODO list, I'll promise to take a look :-)

On 23 December 2013 22:06, bearophile <bearophileHUGS@lycos.com> wrote:

> Iain Buclaw:
>
>
> Did you really think that __simd went through a design phase? :-)
>
> I understand. So there is still a problem bigger than __simd.
>

To be fair, I don't think this is as significant as it sounds. I agree,
__simd had no real design, it was just a convenient implementation for DMD,
but isn't that always the case for compiler intrinsics? In most cases, LLVM
tries to mirror GCC intrinsics, but there are many significant distinctions
between LLVM and GCC's intrinsics, making versions in the code for each
compiler there too.
In my experience, there is always versioning issues when making use of
compiler intrinsics, what's important is that the language is able to wrap
them up cleanly and effectively. D currently satisfies this requirement to
some extent, but in my experience with std.simd, to get to the 100% mark, I
really need __forceinline. I can't really finish std.simd to a satisfactory
level without it.

On 23 December 2013 23:02, Manu <turkeyman@gmail.com> wrote:
> On 23 December 2013 22:06, bearophile <bearophileHUGS@lycos.com> wrote:
>>
>> Iain Buclaw:
>>
>>
>> Did you really think that __simd went through a design phase? :-)
>>
>> I understand. So there is still a problem bigger than __simd.
>
>
> To be fair, I don't think this is as significant as it sounds. I agree,
> __simd had no real design, it was just a convenient implementation for DMD,
> but isn't that always the case for compiler intrinsics? In most cases, LLVM
> tries to mirror GCC intrinsics, but there are many significant distinctions
> between LLVM and GCC's intrinsics, making versions in the code for each
> compiler there too.
> In my experience, there is always versioning issues when making use of
> compiler intrinsics, what's important is that the language is able to wrap
> them up cleanly and effectively. D currently satisfies this requirement to
> some extent, but in my experience with std.simd, to get to the 100% mark, I
> really need __forceinline. I can't really finish std.simd to a satisfactory
> level without it.

We have an @attribute("forceinline") for that... :o)

And sorry, but some compiler intrinsics for DMD really do just shoot themselves in the foot.

On 24 December 2013 09:37, Iain Buclaw <ibuclaw@gdcproject.org> wrote:

> On 23 December 2013 23:02, Manu <turkeyman@gmail.com> wrote:
> > On 23 December 2013 22:06, bearophile <bearophileHUGS@lycos.com> wrote:
> >>
> >> Iain Buclaw:
> >>
> >>
> >> Did you really think that __simd went through a design phase? :-)
> >>
> >> I understand. So there is still a problem bigger than __simd.
> >
> >
> > To be fair, I don't think this is as significant as it sounds. I agree, __simd had no real design, it was just a convenient implementation for
> DMD,
> > but isn't that always the case for compiler intrinsics? In most cases,
> LLVM
> > tries to mirror GCC intrinsics, but there are many significant
> distinctions
> > between LLVM and GCC's intrinsics, making versions in the code for each
> > compiler there too.
> > In my experience, there is always versioning issues when making use of
> > compiler intrinsics, what's important is that the language is able to
> wrap
> > them up cleanly and effectively. D currently satisfies this requirement
> to
> > some extent, but in my experience with std.simd, to get to the 100%
> mark, I
> > really need __forceinline. I can't really finish std.simd to a
> satisfactory
> > level without it.
>
> We have an @attribute("forceinline") for that... :o)
>

DMD doesn't, which is where it's needed the most >_<
Ideally, this needs to be standardised, so compiler-specific intrinsics can
be properly wrapped up.


And sorry, but some compiler intrinsics for DMD really do just shoot
> themselves in the foot.
>

Perhaps, but I'm able to make do with __simd in this case... at least, if I could wrap it effectively.

On 2013-12-24 01:30, Manu wrote:

> DMD doesn't, which is where it's needed the most >_<
> Ideally, this needs to be standardised, so compiler-specific intrinsics
> can be properly wrapped up.

Perhaps you might be able to finish the implementation with GDC. You can sill use @attribute("forceinline") to compile on DMD as well, but it won't to anything, obviously.

-- 
/Jacob Carlborg