View mode: basic / threaded / horizontal-split · Log in · Help
January 05, 2012
Re: System programming in D (Was: The God Language)
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
January 05, 2012
Re: System programming in D (Was: The God Language)
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
January 05, 2012
Re: System programming in D (Was: The God Language)
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?
January 05, 2012
Re: System programming in D (Was: The God Language)
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
January 05, 2012
Re: System programming in D (Was: The God Language)
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.
January 05, 2012
Re: System programming in D (Was: The God Language)
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.
January 05, 2012
Re: System programming in D (Was: The God Language)
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
January 05, 2012
Re: System programming in D (Was: The God Language)
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.
January 05, 2012
Re: System programming in D (Was: The God Language)
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.
January 05, 2012
Re: The God Language
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.
12 13 14 15 16 17 18 19 20
Top | Discussion index | About this forum | D home