View mode: basic / threaded / horizontal-split · Log in · Help
March 18, 2009
new D2.0 + C++ language
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
Re: new D2.0 + C++ language
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
Re: new D2.0 + C++ language
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
Re: new D2.0 + C++ language
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
Re: new D2.0 + C++ language
Weed пишет:
> Hi!
> 

colorized example:
http://paste.dprogramming.com/dpd6j5co
March 18, 2009
Re: new D2.0 + C++ language
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
Re: new D2.0 + C++ language
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
Re: new D2.0 + C++ language
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
Re: new D2.0 + C++ language
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
Re: new D2.0 + C++ language
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
Top | Discussion index | About this forum | D home