www.digitalmars.com         C & C++   DMDScript  

D - Marketplace for D?

reply "Peter Hercek" <vvp no.post.spam.sk> writes:
What is the marketplace for D?
I mean: even if it is not expected to be comercial product,
 it should have target customers. I have read a description
 for target users here: http://www.digitalmars.com/d
But it looks not sufficient to me especially if we compare
 it with Java and C# (or other languages which do translate
 to IL over .net framework). Java, C# and D ... all have
 GC (which is a cool feature and I think required for any
 new language). The only significant difference reamains
 the fact that D does not need runtime. This looks cool,
 but I think it is not so cool as it looks. The main good
 point of "no runtime" feature is that you do not need to
 distribute a lot of executables of the runtime environment.
 Besides this there is a platform dependence for D because
 of this.
When there is no runtime then I would tell, a good target
 for D could be some embedded systems, but these are
 typically real time oriented and D does not have a possibility
 to allocate from memory pool which would not be garbage
 collected and where one would be able to take care about
 memory management yourself. I'm not sure whether
 incremental/coloring garbage collector is enough at least
 for some RT systems (finaly it has an constant time
 overhead with each pointer dereference). Prealocating
 everything may not be an option too.
So I would think like this in a long term:
1) if I'm going to write a bussines application or PC or
   server application, where time or disk space is not critical,
   then I would use Java or C# (.net language), because this
   gives me chance I can run it on a different platform without
   recompile
2) when I'm going to write RT aplication, I continue to be
   struck with C, C++, because D is only garbage collected
3) I can use D for an application which is not time critical and
   which does have a limited diskspace or some other strange
   reason, because of which I cannot use a runtime

Result: Well Java has some performance problems (mostly
 due to some now already "legacy" reasons) and MS can
 screw up its implementations with some proprietary extensions
 or by requesting some fees for ECMA .net framework
 implementations (if I'm correct ECMA does not enforce
 a requirement of free implementations, it requires only
 nondiscriminatory fees or something like that - may be
 this gives MS a possibility to attak e.g. mono implementaion
 later when .net is accepted). Are these two assets (slow
 Java and unreliable MS marketing) the only chance for D?
 Or is market place described in point 3 big enoughf?

It looks to me that it makes *big* sense to allow manual
 memmory alocation / dealocation as an option for D.
 This way one can use D for eg whole firmware with a time
 critical threads withoug CG and other threads with CG.
 (Well if compilers will exist.)

It may be interesting to read C# syntax before finishing
 D syntax. There are some good ideas there, like e.g.
 override keyword etc.
I would also get rid of C style cast operator (type in
 braces). In my opinion this is one of the poorest operators
 in C and it found its way to C# (sadly) and also to D:
It should be something like:
    cast(Type) UnaryExpression
The point is that this operator can be dangerous and if it
 does not have a keyword, its hard to look it up in an
 editor.

Best regards,
       Peter Hercek.
Feb 01 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
Welcome to the crew.


Peter Hercek wrote:
 What is the marketplace for D?

You mean the target usage? D allows for rapid development of high-performance applications, basically like C++, but possibly faster, and in a more unified and safe way. "Shooting yur own feet made complicated."
 I mean: even if it is not expected to be comercial product,
  it should have target customers. I have read a description
  for target users here: http://www.digitalmars.com/d

It might just as well be a commercial product, like some C++ implementations are. But there will be good free ones for sure, like DMD and OpenD.
 But it looks not sufficient to me especially if we compare
  it with Java and C# (or other languages which do translate
  to IL over .net framework). Java, C# and D ... all have
  GC (which is a cool feature and I think required for any
  new language). The only significant difference reamains
  the fact that D does not need runtime. This looks cool,
  but I think it is not so cool as it looks. The main good
  point of "no runtime" feature is that you do not need to
  distribute a lot of executables of the runtime environment.
  Besides this there is a platform dependence for D because
  of this.

D has a standard library. D software shall compile on different platforms without source code change. You can also make platform-dependant optimisations. So platform-dependance is binary level only, which is not necessarily a bad thing. There need not be even a binary platform dependance. It is very well possible to make a special VR for D. Possibly based upon MONO project, which is a .NET VR. It should be possible to use .NET -compatible JIT to create binary-cross-platform D software, it doesn't requiere the rest of the framework. I'm happy to tell you that i'm investigating in this direction. I also argue that having a compiler at hand gives a great nmber of features, like "eval()", and also allows for optimisations in the cases where constants become defined at runtime.
 When there is no runtime then I would tell, a good target
  for D could be some embedded systems, but these are
  typically real time oriented and D does not have a possibility
  to allocate from memory pool which would not be garbage
  collected and where one would be able to take care about
  memory management yourself. 

It does. See phobos library, GC unit, and somewhere below in this newsgroup.
 I'm not sure whether
  incremental/coloring garbage collector is enough at least
  for some RT systems (finaly it has an constant time
  overhead with each pointer dereference). Prealocating
  everything may not be an option too.

Incremental Mark/Sweep doesn't have an overhead, and coloring is non-intrusive. BTW, overhead of coloring systems goes not for pointer dereference, but *only* for pointer writes, which is usually minor. It is expected to optimise a Mark/Sweep GC in D to such extent, that it should not lead to noticable pauses as well. Mind that Walter pointed out, that in C malloc/free can also in principle take arbitrary time, and i bet a coloring collector could make realtime characteristics even better than of C, since all freeing would be done slowly in the background. Well, of yourse you could do that in C yourself, leading to the same result, but the purpose of D is to simplify development. I recommend that you read the thread "garbage collection is bad... other coments" started by Raphael Baptista, who is a game developer (who apparently is obsessed writing and debugging memory managenent spaghetti code), and where all of these has been gone through.
 So I would think like this in a long term:
 1) if I'm going to write a bussines application or PC or
    server application, where time or disk space is not critical,
    then I would use Java or C# (.net language), because this
    gives me chance I can run it on a different platform without
    recompile
 2) when I'm going to write RT aplication, I continue to be
    struck with C, C++, because D is only garbage collected

What does D lack what C/C++ has? You can use all of the same practices in D! You can disable GC and do a manual memory management. I currently argue for 2 separate heaps, one of which is not processed by garbage collection. The feature requieres careful use, but i think it is useful for those who are still unsure.
 3) I can use D for an application which is not time critical and
    which does have a limited diskspace or some other strange
    reason, because of which I cannot use a runtime

D applications are VERY VERY FAST!
 Result: Well Java has some performance problems (mostly
  due to some now already "legacy" reasons) and MS can
  screw up its implementations with some proprietary extensions
  or by requesting some fees for ECMA .net framework
  implementations (if I'm correct ECMA does not enforce
  a requirement of free implementations, it requires only
  nondiscriminatory fees or something like that - may be
  this gives MS a possibility to attak e.g. mono implementaion
  later when .net is accepted). Are these two assets (slow
  Java and unreliable MS marketing) the only chance for D?
  Or is market place described in point 3 big enoughf?

... Almost everything is written in C++ ... And D is a good alternative to it.
 It looks to me that it makes *big* sense to allow manual
  memmory alocation / dealocation as an option for D.
  This way one can use D for eg whole firmware with a time
  critical threads withoug CG and other threads with CG.
  (Well if compilers will exist.)

^^^^ ;) ^^^^ There shall be a GCC port... and GCC is though slow, it exists everywhere. And there might be a "limited" port, which outputs C code and thus will work everywhere.
 It may be interesting to read C# syntax before finishing
  D syntax. There are some good ideas there, like e.g.
  override keyword etc.
 I would also get rid of C style cast operator (type in
  braces). In my opinion this is one of the poorest operators
  in C and it found its way to C# (sadly) and also to D:
 It should be something like:
     cast(Type) UnaryExpression
 The point is that this operator can be dangerous and if it
  does not have a keyword, its hard to look it up in an
  editor.

Exactly this already exists, and Walter intends to get rid of C-style "anonymous" cast as well, since it screws up parsing and interferes with some expressions. Reading manual often helps. Even me. Have fun with D. -i.
Feb 01 2003
next sibling parent "Walter" <walter digitalmars.com> writes:
"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:b1hcks$2tm8$1 digitaldaemon.com...
 Mind that Walter pointed out, that in C malloc/free can also in
 principle take arbitrary time,

I used to think garbage collection was bad, too, until I tried it. I think gc has an undeservedly bad reputation. For example, the DMDScript implementation of javascript that I wrote is TWICE as fast as its nearest competitor, Microsoft Jscript, and up to TWENTY times faster than Mozilla's. Yet DMDScript internally is implemented as a mark/sweep garbage collected interpreter; Mozilla's is not, and I suspect Jscript is reference counted (because COM is).
Feb 01 2003
prev sibling parent reply "Peter Hercek" <vvp no.post.spam.sk> writes:
Hi Ilya,

Thanks for the aswer, you dispelled some of my worries. I'm
 not afraid of GC, I like it and this is a reason I want to move
 some of my projects from C++ to C# or may be Java. I only
 wanted to express that without non-GC-ed memory pool, D is
 too much similar to C# and Java and because of this, it can have
 problems if not pushed by big company. To make it a standard
 with e.g. ECMA may not be enough if it is too close to C#.
 Without a standard it probably does not have a chance at all.
 From this point o view Walter did an excelent decision he did
 not allowed development of more compilers before the
 language is "settled".
I did read the thread "garbage collection is bad... other coments"
 even before I have written my original post. But my post was not
 about whether a GC is good or bad, my post was about who D
 language is targeted to, and how to make it more widely
 accepted in programmers comunity when taking the competitors
 into account (I would like to get rid of some scrap in C and
 C++ too :) ). Because (till you responded) I have thought the
 only interesting difference is the runtime requirement. And to
 make statements that natively compiled code is significantly
 quicker than JIT-ed code requires some courage, especially
 when we take JIT compilers development into account and
 when we do realize that .net allows "precompiled program
 image cache", which is persistent between separate process
 runs.

Do you have a link where the incremental GC is described?
 I have read only about GC, which had both write and read
 guards. And the program spent 10% of execution time only
 by chceking the read checks (not taking into account all
 the other GC execution time). Also the incremental GC seems
 to be very tough problem especially in multiprocessor
 environment ... ironically ... where it should be most required.

I'm temped to believe that, prealocation or incremental GC
 should be enough for most RT or RT like aplications, but
 I'm sure a lot of guys will not think the same way and these
 can clearly decide for D instead of C#, Java.

I like very much you guys decided to get rid of preprocessor
 and to make grammar as simple as possible and without conflicts.
 This will get important for tool implemeters. E.g. editors with
 intelisense and "online" *syntactical* or even some semantical
 checks, case tool integration, ... and one needs this.

Peter Hercek.
Feb 02 2003
parent reply Ilya Minkov <midiclub tiscali.de> writes:
Hello.

  too much similar to C# and Java and because of this, it can have
  problems if not pushed by big company. To make it a standard
  with e.g. ECMA may not be enough if it is too close to C#.
  Without a standard it probably does not have a chance at all.
  From this point o view Walter did an excelent decision he did
  not allowed development of more compilers before the
  language is "settled".

I don't think it requieres a standard, since Walter is one and only and he makes it standard. Standards are only useful when there are tons of people arguing, like in C and C++ case. Every other standard is a farce, even for this case with Microsoft, which was only to show that they don't intend to hold a monoply for some parts of the system, but for others they do. He did not forbid devlopment either. D for linux (DLI) deviates a bit, and allows constructs which are illegal in DMD or standard. And it would be really cool if GCC frontend development could be more productive, but i guess they're just climbing over their first problems yet. Unlike DLI, it would be synchromised to Walter's source. It would merely be a glue layer. And i consider hooking D to .NET, using Walter's source as well. Lacking awareness of D sort of slows down development of other high-quality compilers.
  only interesting difference is the runtime requirement. And to
  make statements that natively compiled code is significantly
  quicker than JIT-ed code requires some courage, especially

Of course a JIT VM execution speed could reach the speed of native-compiled software, but it requieres careful design. No single Java bytecode->native code performs as well as Java source->native compilation. The distributable representation has to retain more information. Maybe .NET (CLI) does exactly that. That's why i'm investigating it. ;) If the distributable representation allows for powerful optimisation, it is merely a tradeoff between execution speed and compilation time. But if profiling information is saved in, this can very well be taken into account. There are also cases where having a mediocre compier at hand can speed up code by order of magnitude, for example in the cases where a great number of constants are set in the beginning and then affect lots of branches and the code behaves almost as interpreted. There has been a proof for it. Look up "Tick C Compiler". Results are clearly impressing, scoring often much better than GCC -O2, although compiler used for dynamic compilation is real crap. But then again, it requeres high-level analysis, what should be re-compiled when, or "hints" in the programme.
 Do you have a link where the incremental GC is described?
  I have read only about GC, which had both write and read
  guards. And the program spent 10% of execution time only
  by chceking the read checks (not taking into account all
  the other GC execution time). Also the incremental GC seems
  to be very tough problem especially in multiprocessor
  environment ... ironically ... where it should be most required.

It was probably a JAVA GC? It's lame. And intrusive. Mark/Sweep collector does not have any guards. It just stops program execution and marks all used objects. After that, execution is continued as normal, and garbage is recycled in the background. Marking is only invoked at memory allocation, or at programmer's descretion. So it's very little intrusive, and no slowdown at all. "Conservative" Mark/Sweep GCs used in C are multiple orders of magnitude more intrusive than the one D shall get soon because of lacking type information. Three-colour collector needs only pointer write guards, i have already described it in "Re: GC is bad...". OCaml uses a variant of it. It's a slowdown, but not intrusive, and keeps memory footprint small. For papers on different methods of garbage collection, look at http://www.memorymanagement.org/ I just can't remember where i took information from, but i guess it's all there. In the thread "Improving garbage collection", Evan suugests this document for reading: http://cs.anu.edu.au/~Steve.Blackburn/pubs/papers/beltway-pldi-2002.pdf He said that he has changed sides after reading it. -i.
Feb 03 2003
parent "Peter Hercek" <vvp no.post.spam.sk> writes:
Hi Ilya,

Well, I have not looked in here almost for a week :)

As for as the standardization - I hope it will work as you did
 describe. I think that a posibility to change compiler and still
 compile sucessfuly is very important.

"Ilya Minkov" <midiclub tiscali.de> wrote in message
news:b1lq6u$2ffk$1 digitaldaemon.com...
[cut]---------------------------------------------------------
  > Do you have a link where the incremental GC is described?
  >  I have read only about GC, which had both write and read
  >  guards. And the program spent 10% of execution time only
  >  by chceking the read checks (not taking into account all
  >  the other GC execution time). Also the incremental GC seems
  >  to be very tough problem especially in multiprocessor
  >  environment ... ironically ... where it should be most required.

 It was probably a JAVA GC? It's lame. And intrusive.

No, it was some collector used in lisp (I think - not sure about this - it was also an implementation for a single processor only). Later, after your previous post, I have seen a paper about a collector with write guards only, but it was very long and very complicated and for multiprocesor environment only (nothing like a quick introduction how it aprocimately works - it looked more like "spend two days with me" :-) ). Thank you for the links. Peter.
Feb 07 2003