<div dir="ltr">On 8 April 2013 17:59, Dicebot <span dir="ltr"><<a href="mailto:m.strashun@gmail.com" target="_blank">m.strashun@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Monday, 8 April 2013 at 06:35:27 UTC, Paulo Pinto wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I do understand that, the thing is that since I am coding in 1986, I remember people complaining that C and Turbo Pascal were too slow, lets code everything in Assembly. Then C became alright, but C++ and Ada were too slow, god forbid to call virtual methods or do any operator calls in C++'s case.<br>

<br>
Afterwards the same discussion came around with JVM and .NET environments, which while making GC widespread, also had the sad side-effect to make younger generations think that safe languages require a VM when that is not true.<br>

<br>
Nowadays template based code beats C, systems programming is moving to C++ in mainstream OS, leaving C behind, while some security conscious areas are adopting Ada and Spark.<br>
<br>
So for me when someone claims about the speed benefits of C and C++ currently have, I smile as I remember having this kind of discussions with C having the role of too slow language.<br>
</blockquote>
<br></div>
But important question is "what has changed?". Was it just shift in programmer opinion and they initially mislabeled C code as slow or progress in compiler optimizations was real game-breaker? Same for GC's and VM's.<br>

<br>
It may be perfectly possible to design GC that suits real-time needs and is fast enough (well, Manu has mentioned some of requirements it needs to satisfy). But if embedded developers need to wait until tool stack that advanced is produced for D to use it - it is pretty much same as saying that D is dead for embedded. Mythical "clever-enough compilers" are good in theory but job needs to be done right now.<br>

</blockquote></div><br></div><div class="gmail_extra" style>D for embedded, like PROPER embedded (microcontrollers, or even raspberry pi maybe?) is one area where most users would be happy to use a custom druntime like the ones presented earlier in this thread where it's strategically limited in scope and designed not to allocate. 'Really embedded' software tends not to care so much about portability.<br>
</div><div class="gmail_extra" style>A bigger problem is D's executable size, which are rather 'plump' to be frank :P</div><div class="gmail_extra" style>Last time I tried to understand this, one main issue was objectfactory, and the inability to strip out unused classinfo structures (and other junk). Any unused data should be stripped, but D somehow finds reason to keep it all. Also, template usage needs to be relaxed. Over-use of templates really bloats the exe. But it's not insurmountable, D could be used in 'proper embedded'.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>For 'practically embedded', like phones/games consoles, the EXE size is still an issue, but we mainly care about performance. Shrink the EXE, improve the GC.</div>
<div class="gmail_extra" style>There's no other showstoppers I'm aware of. D offers you as much control as C++ over the rest of your performance considerations, I think they can be addressed by the programmer.</div>
<div class="gmail_extra" style>That said, I'd still KILL for __forceinline! ;) ;)</div></div>