<div class="gmail_quote">On 11 December 2011 20:34, Paulo Pinto <span dir="ltr"><<a href="mailto:pjmlp@progtools.org">pjmlp@progtools.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Am 11.12.2011 19:18, schrieb Manu:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 11 December 2011 15:15, maarten van damme <<a href="mailto:maartenvd1994@gmail.com" target="_blank">maartenvd1994@gmail.com</a><br></div><div class="im">
<mailto:<a href="mailto:maartenvd1994@gmail.com" target="_blank">maartenvd1994@gmail.<u></u>com</a>>> wrote:<br>
<br>
<br>
2011/12/11 Paulo Pinto <<a href="mailto:pjmlp@progtools.org" target="_blank">pjmlp@progtools.org</a><br></div>
<mailto:<a href="mailto:pjmlp@progtools.org" target="_blank">pjmlp@progtools.org</a>>><div><div class="h5"><br>
<br>
Am 10.12.2011 21:35, schrieb Andrei Alexandrescu:<br>
<br>
On 12/10/11 2:22 PM, maarten van damme wrote:<br>
<br>
Just for fun I<br>
wanted to create a program as little as possible,<br>
compiled without<br>
garbage collector/phobos/... and it turned out that<br>
compiling without<br>
garbage collector is pretty much impossible (memory<br>
leaks all around the<br>
place in druntime). dynamic linking for the d standard<br>
library would be<br>
a great new option for a dmd release in the future :).<br>
<br>
<br>
Using D without GC is an interesting direction, and dynamic<br>
linking<br>
should be available relatively soon.<br>
<br>
<br>
Andrei<br>
<br>
<br>
As a long time beliver in systems programming languages with GC<br>
support<br>
(Modula-3, Oberon, Sing#, ...), I think allowing this in D is<br>
the wrong direction.<br>
<br>
Sure provinding APIs to control GC behavior makes sense, but not<br>
turn it<br>
off, we already have enough languages to do systems programming<br>
without GC.<br>
<br>
<br>
I was only trying it "for the fun of it", not to be used seriously.<br>
D should always have it's GC support built-in and have some<br>
functions to control it's behaviour (core.memory). But I think that<br>
D, beeing a systems programming language, should also be able to be<br>
used without GC. I don't mean phobos to be writtin without a GC in<br>
mind but druntime should be compilable with something like a -nogc<br>
flag that make it usable without GC.<br>
<br>
There are a lot of users out there who think that a GC produces<br>
terribly slow programs, big hangs while collecting,... (thank java<br>
for that. Right now the java GC has been improved and it's extremely<br>
good but the memory stays :p)<br>
Letting them know that D can be run without GC can be a good point.<br>
If they don't like it, they can turn it off.<br>
<br>
<br></div></div><div class="im">
That's got nothing to do with it. People who seriously NEED to be able<br>
to use the language without the GC enabled are probably working on small<br>
embedded systems with extremely limited resources. It's also possible<br>
that various different resource types need to be allocated/located in<br>
different places.<br>
Also, In many cases, you need to able to have confidence in strict<br>
deterministic allocation patterns. You can't do that with a GC enabled.<br>
I'm all about having a GC in D, obviously, but I certainly couldn't<br>
consider the language for universal adoption in many of my projects<br>
without the option to control/disable it at times.<br>
If I can't write some small programs with the GC completely disabled,<br>
then I basically can't work on microprocessors. It's fair to give up the<br>
standard library when working in this environment, but druntine, the<br>
fundamental library, probably still needs to work. Infact, I'd<br>
personally like it if it was designed in such a way that it never used<br>
the GC under any circumstances. No library FORCED on me should restrict<br>
my usage of the language in such a way.<br>
</div></blockquote>
<br>
In my experience programming embedded systems in highly constrained environments usually means assembly or at most a C compiler using lots<br>
of compiler specific extensions for the target environment.<br>
<br>
I fail to see how D without GC could be a better tool in such enviroments.<br></blockquote><div><br></div><div>The best current example I can think of is PS3, there are 2 separate architectures in use in that machine, PPC, and SPU, the PPC has 2 separate heaps, and each SPU has its own 256k micro-heap.</div>
<div>The PPC side would probably use GC in the main heap, and manually manage resources in the secondary video heap. Each SPU however is a self contained processor with 256k of memory.</div><div>Not only is there no room to waste, but the PROGRAM needs to fit in there too. Interaction between the main program and the SPU micro-programs is FAR more painless if they share the same language. With the source code being shared, it's very easy to copy memory between the processors which directly share the structure definitions.</div>
<div>Obviously, any code running on the SPU may not use the GC... Period. The program code its self must also be as small as possible, no space to wastefully link pointless libraries.</div><div><br></div><div>It's hard to say a PS3 isn't a fair target platform for a language like D. It's not going away either.</div>
<div>This is just one example, almost every games console works like this:</div><div> * PS2 had 4 coprocessors, each with their own micro-memory, one of which would certainly share source code with the main app (even back then, this approach was the norm).</div>
<div> * PSP only has 32mb of ram, explicit management is mandatory on systems with such small memory.</div><div> * Wii has an ARM coprocessor with a tiny memory bank, it also has bugger-all main memory (24mb), so you probably want to explicitly manage memory a lot more.</div>
<div> * Nintendo DS has a secondary small coprocessor.</div><div> * Larrabee architecture, CELL architecture, or anything like these it will require running code with explicit management of micro-heaps.</div><div><br></div>
<div>Signal processing, DSP's, etc, usually coprocessors, these aren't tiny slave chips with microprograms written in assembly anymore, they are powerful sophisticated coprocessors, with full floating point (usually SIMD arithmetic, PLEASE PLEASE ADD A 128bit SIMD TYPE) support, would benefit from D and its libraries, but still have bugger all memory and require strict control over it.</div>
<div><br></div><div>It's nice to write the master program and the coprocessor programs in the same language. At very least for the ability to directly share data structs.</div><div><br></div><div>I hope I have made an indisputable a case for this. It's come up here a lot of times, and it's pretty annoying when everyone suggests the reasons for wanting it are nothing more that maximising performance. I'd suggest that in 95% of cases, performance has <u>nothing</u> to do with it.</div>
</div>