Inherent code performance advantages of D over C?

[Manu]

On 14 December 2013 01:42, Dicebot <public at dicebot.lv> wrote:

> On Thursday, 12 December 2013 at 13:17:14 UTC, Manu wrote:
>
>> But that's not a concern for typical programmers. That the responsibility
>> of sysadmins.
>> What I meant was, 'what's more valuable [to a programmer]...'
>>
>
> Leaning dangerously close to philosophy here :)
>

Can you offer an alternative? :)


 Our choice to use C rather than C++ was in a sense, a funny way to enforce
>> a coding standard. Like I say, it forces simplicity, and a consistent
>> approach to problems.
>>
>
> When I was speaking about "domains where C is still necessary" I was not
> opposing it to C++ but other modern languages in general. Even real-time
> service development is quite possible using stuff like Erlang these days.
> Okay, there is also gamedev which I won't dare to speak about :) But in
> general there is no much sense to speak about replacing C and imagining any
> "normal" userspace application, even performance-critical.
>
> Some time ago I have been part of project that completely changed my image
> of what C domain can be. It remains most mind-blowing experience in my
> programming history (which is damn short of course but can't resist
> dramatical intro). Project was in mobile networking / LTE domain with huge
> amount of people involved all over the world. Specifically our team in
> Latvia was responsible for node cluster software which acted essentially as
> a giant router + firewall. Actual nodes were custom multi-core MIPS
> machines with h/w implementation of event loop and part of IP stack
> handling. All actual packet processing code ran as barebone executables -
> no OS, not virtual memory or any fancy stuff, just platform SDK you take to
> build single processing binary which is than loaded at hard-coded memory
> address (all remaining memory is pre-allocated for packet handling
> purposes). No really complicated processing algorithms or anything like
> that but everyone was extremely picky about tiny details how this binary
> was actually running - making sure no instruction cache misses happen under
> normal workflow for each core, connection context struct fits into single
> cache line and stuff like that. And one of my responsibilities was actual
> performance testing of that system so I could have observed how much of an
> impact those seemingly small tweaks have made.
>
> And now every time I hear that "language X can do all stuff C can" I
> imagine myself trying to sell this to other guys working on that project
> and have an extremely hard time doing this even in my imagination.
>

Heh, this sounds pretty much like my life. The same discipline applies to
any realtime embedded software (read: video game console). I'm brutally
conscious of all the details you mention.
I don't think D is incompatible with this at all though. It was early last
year... until I convinced Walter to implement align() properly. Now we're
good! :)
I could still REALLY do with __forceinline though. D doesn't have an
effective macro.
Obviously, if by 'language X' you mean 'any non-compiled language with
pointers', then I totally agree! People who make claims like you say, don't
generally know what they're talking about, or what C is actually used for.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131214/5e022ede/attachment.html>