March 18, 2009
Hi!

I want to offer the dialect of the language D2.0, suitable for use where are now used C/C++. Main goal of this is making language like D, but corresponding "zero-overhead principle" like C++:

- Its does not contains garbage collection and
- allows active using of a stack for the objects (as in C++)
- Its uses syntax and a tree of objects taken from the D

The code on this language almost as dangerous as a code on C++ - it is a necessary cost for increasing performance.

Compiler for that language does not exist! And it is unlikely that I will be able to do it. In any case, I want to discuss before thinking about compiler.

I just give you an example of using, without a description of pure syntax because I do not propose anything new for those who remember C++ and D.

Ask the questions!


/*
Demonstration of a new dialect of the D language
It describes only what differs from D2.0

This language is compatible with C and (probably) D ABI, but not with C++.
*/


/*
Structures and classes are completely similar, except structs are having
controlled
alignment and the lack of polymorphism.

The structures are POD and fully compatible with the structures of the
language C.
*/
struct S {
    int var0;
    int var1;
    int var2;

    // Structs constructors are entirely same as in a classes:
    this() {
        var1 = 5;
    }
}

interface I {
    void incr();
}

// The structures is a POD.
// They supports inheritance without a polymorphism and they support
// interfaces too.
struct SD : S, I {
    int var3;
    int var4;

    void incr() { ++var3; ++var4; }

    /*
    Structs constructors are similar to the class constructors.
    Calling base constructor super () is required.
    */
    this() {
        super();
        var4 = 8;
    }
}

class C, I {
    int var;
    void incr() { ++var; }

    /*
    Instead of overloading the operator "=" for classes and structures,
    there is present constructor, same as the copy constructor in C++ -
    in the parameters it accepts only
    object of the same type.
    This is differs from D and the need to ensure that copy constructor
    can change the source object
    (for example, to copy objects linked to the linked-list).

    Unlike the C++ constructor, it first makes a copy of the bitwise
    the original object, then an additional postblit, the same way as
    occurs in D2.0. This allows increase performance of copying than in
    C++.

    And about references:
    When compiling with "-debug" option compiler builds binary with the
    reference-counting.
    This approach is criticized by Walter Bright there:
        http://www.digitalmars.com/d/2.0/faq.html#reference-counting

    But, if the language is not have GC, reference-counting is a good
    way to make sure that
    the object which it references exists. The cost - an additional
    pointer dereferencing and
    checking the counter (and this is only when compiling with option
    "-debug"!).
    */
    this( ref C src ) {
        var3 = src.var3;
        var4 = src.var4;
    }
}

class CD : C {
    real var2;
    void dumb_method() {};
}


void func()
{
    /*
    Classes to be addressed in the heap by pointer. "*" need to
    distinguish the classes in
    heap of classes in the stack. I.e., creating classes and structures
    takes place the same as creating
    them in the C++.
    */
    CD  cd_stack;         // Creates class in a stack
    CD* cd_heap = new CD; // Creates class in a heap, new returns
                          // pointer (same as in C++)
    C*  c_heap  = new C;
    C   c_stack;

    // Copying of a objects (same as in C++)
    cd_stack = *cd_heap;
    *cd_heap = cd_stack;

    /*
    Copying of a pointers to the objects

    "c_heap" pointer points to the object "cd_heap", with the object to
     which the previously pointed "c_heap" is not removed (as there is
    no GC and not used smartpointer template).
    This is memory leak!
    */
    c_heap = cd_heap;

    /*
    "Slicing" demo:

    As a parent object is copied from derived class with additional
    fields and methods. The "real var2" field data is not available in
    "c_stack" and not will be copied:
    */
    c_stack = *cd_heap;

    /*
    Attempt to place an object of type C into the derived object of type
    CD. Field real var2 is not filled by C object. There field now
    contains garbage:
    */
    cd_stack = c_stack;
    cd_stack.var2; // <- garbage data

}
March 18, 2009
Weed:
> I want to offer the dialect of the language D2.0, suitable for use where are now used C/C++. Main goal of this is making language like D, but corresponding "zero-overhead principle" like C++:
>...
> The code on this language almost as dangerous as a code on C++ - it is a necessary cost for increasing performance.

No, thanks...

And regarding performance, eventually it will come a lot from a good usage of multiprocessing, that in real-world programs may need pure functions and immutable data. That D2 has already, while C++ is less lucky.

Bye,
bearophile
March 18, 2009
Weed Wrote:

> - Its does not contains garbage collection and
> - allows active using of a stack for the objects (as in C++)
> - Its uses syntax and a tree of objects taken from the D

Garbage collection can be turned off already, you can get rid of it just by minor modification of druntime, stack allocation is also a minor modification to the compiler, you just need to add syntactical support for it.
March 18, 2009
Kagamin Wrote:

> Weed Wrote:
> 
> > - Its does not contains garbage collection and
> > - allows active using of a stack for the objects (as in C++)
> > - Its uses syntax and a tree of objects taken from the D
> 
> you just need to add syntactical support for it.

...well, you already has it with structure constructors...
March 18, 2009
Weed пишет:
> Hi!
> 

colorized example:
http://paste.dprogramming.com/dpd6j5co
March 18, 2009
Kagamin пишет:
> Kagamin Wrote:
> 
>> Weed Wrote:
>>
>>> - Its does not contains garbage collection and
>>> - allows active using of a stack for the objects (as in C++)
>>> - Its uses syntax and a tree of objects taken from the D
>> you just need to add syntactical support for it.
> 

Yes

> ...well, you already has it with structure constructors...

Remember that we have already discussed this here several times, and came to the conclusion (?) that emulation of the "value semantic" by structs unreasonably difficult

March 18, 2009
bearophile пишет:
> Weed:
>> I want to offer the dialect of the language D2.0, suitable for use where
>> are now used C/C++. Main goal of this is making language like D, but
>> corresponding "zero-overhead principle" like C++:
>> ...
>> The code on this language almost as dangerous as a code on C++ - it is a
>> necessary cost for increasing performance.
> 
> No, thanks...
> 
> And regarding performance, eventually it will come a lot from a good usage of multiprocessing,

The proposal will be able support multiprocessing - for it provided a references counting in the debug version of binaries. If you know the best way for language *without GC* guaranteeing the existence of an object without overhead - I have to listen!

> that in real-world programs may need pure
> functions and immutable data.

I do not see any problems with this

> That D2 has already, while C++ is less lucky.

March 18, 2009
Reply to Weed,

> If you know the
> best way for language *without GC* guaranteeing the existence of an
> object without overhead - I have to listen!
> 

Never delete anything?

One of the arguments for GC is that it might well have /less/ overhead than any other practical way of managing dynamic memory. Yes you can be very careful in keeping track of pointers (not practical) or use smart pointers and such (might end up costing more than GC) but neither is particularly nice.


March 18, 2009
bearophile Wrote:

> Weed:
> > I want to offer the dialect of the language D2.0, suitable for use where are now used C/C++. Main goal of this is making language like D, but corresponding "zero-overhead principle" like C++:
> >...
> > The code on this language almost as dangerous as a code on C++ - it is a necessary cost for increasing performance.
> 
> No, thanks...
> 
> And regarding performance, eventually it will come a lot from a good usage of multiprocessing, that in real-world programs may need pure functions and immutable data. That D2 has already, while C++ is less lucky.
> 
> Bye,
> bearophile

Multiprocessing can only improve performance for tasks that can run in parallel.  So far, every attempt to do this with GC (that I know of) has ended up slower, not faster.  Bottom line, if GC is the bottleneck, more CPU's won't help.

For applications where GC performance is unacceptable, we either need a radically new way to do GC faster, rely less on the GC, or drop GC altogether.

However, in D, we can't get rid of the GC altogether, since the compiler relies on it.  But we can use explicit memory management where it makes sense to do so.

-Craig
March 18, 2009
Wed, 18 Mar 2009 13:48:55 -0400, Craig Black wrote:

> bearophile Wrote:
> 
>> Weed:
>>> I want to offer the dialect of the language D2.0, suitable for use where are now used C/C++. Main goal of this is making language like D, but corresponding "zero-overhead principle" like C++:
>>>...
>>> The code on this language almost as dangerous as a code on C++ - it is a necessary cost for increasing performance.
>> 
>> No, thanks...
>> 
>> And regarding performance, eventually it will come a lot from a good usage of multiprocessing, that in real-world programs may need pure functions and immutable data. That D2 has already, while C++ is less lucky.
>> 
>> Bye,
>> bearophile
> 
> Multiprocessing can only improve performance for tasks that can run in parallel.  So far, every attempt to do this with GC (that I know of) has ended up slower, not faster.  Bottom line, if GC is the bottleneck, more CPU's won't help.
> 
> For applications where GC performance is unacceptable, we either need a radically new way to do GC faster, rely less on the GC, or drop GC altogether.
> 
> However, in D, we can't get rid of the GC altogether, since the compiler relies on it.  But we can use explicit memory management where it makes sense to do so.
> 
> -Craig

I think that the "shared" memory concept in D2 is introduced specifically to improve multi-processing GC performance.  There going to be thread-local GC for every thread allocating memory, and, since thread-local will be the default allocation strategy, most memory will be GCed without synchronizing with other threads.
« First   ‹ Prev
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home