On 01/05/12 02:34, Iain Buclaw wrote:
> Code that gdc emits is incompatible with the standard D compiler, if that's what you want to call it, and any vendor extensions won't contribute to that being more of the case.
> 
> Regardless, there is little reason to want to use a forced inline with gdc.  Just like in c++ when you define all methods in the class definition, gdc considers all methods as candidates for inlining. Similarly, when -inline is passed, the same is also done for normal functions that are considered inlinable by the frontend.  These functions marked as inline are treated in the same way as a function declared 'inline' in C or C++, and will be treated as such by the backend.

"C" inline is, for historical reasons, ill-defined; i think what people are talking about in the context of D is the equivalent of gcc attribute(always_inline). Ie it's for the cases where not inlining is not an option. Having an explicit C-style "inline" hint is pointless - the compiler should be able to guess this right most of the time. It's for the cases where the programmer already knows the answer and is not willing to let the tool make a mistake.

artur

On 01/05/12 02:34, Iain Buclaw wrote:
> Regardless, there is little reason to want to use a forced inline with gdc.  Just like in c++ when you define all methods in the class definition, gdc considers all methods as candidates for inlining. Similarly, when -inline is passed, the same is also done for normal functions that are considered inlinable by the frontend.  These functions marked as inline are treated in the same way as a function declared 'inline' in C or C++, and will be treated as such by the backend.

This reminded me:

------------------------------------
bool empty1(T)(T[] a)    { return 1; }
bool empty2(T)(in T[] a) { return 1; }

int main(string[] argv) {
   auto r1 = empty1(argv[0]);
   auto r2 = empty2(argv[0]);
   return r1&&r2;
}
------------------------------------

results in:
------------------------------------
# gdc -O3 -finline -frelease -fno-bounds-check notinlined.d -o notinlined

08049ac0 <bool notinlined.empty1!(immutable(char)).empty1(immutable(char)[])>:
 8049ac0:       55                      push   %ebp
 8049ac1:       b8 01 00 00 00          mov    $0x1,%eax
 8049ac6:       89 e5                   mov    %esp,%ebp
 8049ac8:       5d                      pop    %ebp
 8049ac9:       c3                      ret

08049ad0 <bool notinlined.empty2!(immutable(char)).empty2(const(immutable(char)[]))>:
 8049ad0:       55                      push   %ebp
 8049ad1:       b8 01 00 00 00          mov    $0x1,%eax
 8049ad6:       89 e5                   mov    %esp,%ebp
 8049ad8:       5d                      pop    %ebp
 8049ad9:       c3                      ret

08049ae0 <_Dmain>:
 8049ae0:       55                      push   %ebp
 8049ae1:       89 e5                   mov    %esp,%ebp
 8049ae3:       83 ec 18                sub    $0x18,%esp
 8049ae6:       8b 45 0c                mov    0xc(%ebp),%eax
 8049ae9:       8b 50 04                mov    0x4(%eax),%edx
 8049aec:       8b 00                   mov    (%eax),%eax
 8049aee:       89 54 24 04             mov    %edx,0x4(%esp)
 8049af2:       89 04 24                mov    %eax,(%esp)
 8049af5:       e8 d6 ff ff ff          call   8049ad0 <bool notinlined.empty2!(immutable(char)).empty2(const(immutable(char)[]))>
 8049afa:       c9                      leave
 8049afb:       0f b6 c0                movzbl %al,%eax
 8049afe:       c3                      ret

------------------------------------

IOW gdc completely gives up on inlining the function/method because of the "in".
Actually, "bool empty2(T)(const T[] a)" is enough to trigger the call.

This means that eg array.empty never gets inlined. "pragma(attribute, always_inline)" does not help in this case.

artur

On 5 January 2012 03:34, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> Regardless, there is little reason to want to use a forced inline with gdc.  Just like in c++ when you define all methods in the class definition, gdc considers all methods as candidates for inlining. Similarly, when -inline is passed, the same is also done for normal functions that are considered inlinable by the frontend.  These functions marked as inline are treated in the same way as a function declared 'inline' in C or C++, and will be treated as such by the backend.
>

How is this possible, when all functions are virtual, without whole program optimisation?

On 2012-01-05 10:54, Artur Skawina wrote:
> On 01/05/12 08:19, Jacob Carlborg wrote:
>> On 2012-01-04 16:31, Artur Skawina wrote:
>>> On 01/04/12 10:39, Manu wrote:
>>>> Walter made an argument "The same goes for all those language extensions you mentioned. Those are not part of Standard C. They are vendor extensions. Does that mean that C is not actually a systems language? No."
>>>> This is absurd... are you saying that you expect Iain to add these things to GDC to that people can use them, and then create incompatible D code with the 'standard' compiler?
>>>
>>> Some of these things are *already* in GDC... Probably not documented and tested enough [1], but they are there. So you /can/ have function declarations such as:
>>>
>>> pragma(GNU_attribute, always_inline, flatten, hot) int fxx(int i) { ... }
>>
>> If you want your code to be portable (between compilers) you would need to wrap that in a version statement.
>>
>
> Exactly. Which isn't a problem if you have one or two such functions. But becomes one when you have hundreds. And different compilers use different conventions, some do not support every feature and/or need specific tweaks. Copy-and-pasting multiline "declaration attribute blocks" for every function that needs them does not really scale well.
> In C/C++ this is CPP territory where you solve it with a #define, and all of the magic is both hidden and easily accessible in one place. Adding support for another compiler requires only editing of that one header, not modifying practically the whole project. Let's not even think about compiler version specific tweaks (due to compiler bugs or features appearing in newer versions)...
>
> D, being in its infancy, may have been able to ignore these issues so far (having only one D frontend helps too), but w/o a std, every vendor will have to invent a way to expose non-std features. For common things such as forcing functions to be inlined, keeping them out of line, marking them as hot/cold, putting them in specific text sections etc relying on vendor extensions is not really necessary.
>
> It's bad enough that every compiler will use a different incompatible runtime, in some cases calling conventions - and consequently different shared libraries; reducing source code portability (even if just by making things harder than they should be) will lead to more balkanization...
>
> artur

The pragma is a standard way to expose non-standard features. You just need to wrap it in version statements because the compiler will otherwise complain about unrecognized pragmas. If that's a good thing or not, I don't know.

-- 
/Jacob Carlborg

About your junior comment, are virtuals really the biggest thing you should worry about? There are infinitely many things a newbie programmer will screw up (think linear algorithms, excessive memory allocation, hardcoded, non-modular and thread-unsafe code, etc). I think virtual calls are likely to be just *one* of your problems, and probably not the biggest one.

Btw, I think people are having a misconception on what it means that D is a systems-programming language. It doesn't mean that D by default generates the fastest code and trades safety for performance, it means it *allows* you to write such code. But you need to be aware of what you're coding.

On Thursday, 5 January 2012 at 13:40:20 UTC, Jacob Carlborg wrote:
> The pragma is a standard way to expose non-standard features. You just need to wrap it in version statements because the compiler will otherwise complain about unrecognized pragmas. If that's a good thing or not, I don't know.

DMD has an -ignore switch:

 -ignore        ignore unsupported pragmas

On 5 January 2012 15:44, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> About your junior comment, are virtuals really the biggest thing you should worry about?


Sure it's not the biggest thing, it's one of numerous things. You'll notice
a listed a whole bunch of things in my post, and this isn't my thread,
these were in addition to the OP's comments.
I'm just trying to add some weight to the OP's sentiments, in that I feel
the same way in many areas after a few weeks of experience with D and
writing some programs, and considering it for use in future projects.


> There are infinitely many things a newbie
> programmer will screw up (think linear algorithms, excessive memory
> allocation, hardcoded, non-modular and thread-unsafe code, etc). I
> think virtual calls are likely to be just *one* of your problems, and
> probably not the biggest one.
>

The point is that this is one thing that is completely silently hidden, and
the language could fix this tremendously easily by nothing more than a
trivial decision of what is default.
I realise that's unlikely to happen, this decision is done now, but I think
it's important to raise this sort of issue anyway, so that future decisions
have more points in the balance.

It would also be generally nice if these concerns were acknowledged rather than brushed off. I'm not making problems for the sake of conversation. These are real issues that I encounter in my daily work.

On 01/05/2012 10:02 AM, Manu wrote:
>...
> Also, D is NOT a good compiler, it's a rubbish compiler with respect to
> code generation.
> [snip.]

D is not a compiler, it is a language. Furthermore it is not true that DMDs backend is rubbish and there are already more backends than just the DMC backend.

DMD: DMC backend, _fast code gen_ and very pleasant to use for debug builds.

GDC: GCC backend, optimizes as well as GCC. This is what I use for release. Takes about three times longer for a debug build than DMD. A lot less usable for edit-compile-test cycle than DMD.

LDC: LLVM backend, implements some additional optimizations in the front end. I don't have LDC installed, but iirc it is also a lot slower than DMD.

I think it would be nice if you stopped spreading FUD. You seem to have reasonable requests.

On Thursday, 29 December 2011 at 09:16:23 UTC, Walter Bright wrote:
> http://pastebin.com/AtuzJqh0

I thought this topic was about a mix of Go (Google Language) and D.