On 8 April 2013 18:22, Manipulator <volcz@kth.se> wrote:

> I just re-read the "Doom3 Source Code Review" by Fabien Sanglard (
> http://fabiensanglard.net/**doom3/ <http://fabiensanglard.net/doom3/>)
> and apparently they don't use the Standard C++ library. "The engine does
> not use the Standard C++ Library: All containers (map,linked list...) are
> re-implemented but libc is extensively used."
> I certainly feel that there is room for improvement, like optimizing the
> GC, define a GC-free subset of Phobos etc. But it seems like if you're
> writing really performance critical realtime software most likely you've to
> implement everything bottom up to get the level of control.
>

I think it's important to realise though, that id software (and most game
devs for that matter) only implement their own containers/etc because C++
utterly failed them.
My whole point here is to make sure D gets it right in the std lib, so
people don't have to waste that time.
Rolling your own containers (or working upon any non-standard libs) leads
to generally incompatible code. Try plugging library X with its own set of
containers into application Y. If D fails on this front, I think it will
fail as a candidate for these developers; it will not be selected by
realtime developers trying to escape C++.
I suspect Andrei for one knows this, and that's why the D containers are
so... barely existing. The language is not yet ready to say with confidence
how they should look.

Performance critical shouldn't be incompatible with the notion of a standard library. It just means the standard library authors didn't give a shit, and I hope that doesn't transfer into D long-term... :/


Secondly it seems like it's most often cheaper to just throw faster
> hardware at a problem.
> "You can do tricks to address any one of them; but I pretty strongly
> believe that with all of these things that are troublesome in graphics,
> rather than throwing really complex algorithms at them, they will
> eventually fall to raw processing power."(http://fabiensanglard.**
> net/doom3/interviews.php <http://fabiensanglard.net/doom3/interviews.php>)
>

You saw the AMD guy who recently came out and said "moores law is over", right? ;)

Remember that you're reading an article by a PC developer. The thing about
phones and games consoles (particular games consoles, since they have a
10-ish year lifetime... phones are more like 6 months, but they'll slow
with time), and now sunglasses (god knows what next!), is that they're
fixed hardware. The developers are required to compete to get the most out
of a fixed machine.
The language/libs need to help with this and not waste everyones time. If
the library is particularly bad, the developers will rewrite it themselves,
at expense of time, sanity, and portability.

I've reinvented more wheels in my career than I care to imagine. Actually,
It's probably not a far fetched call to say I've spent MOST of my working
life re-inventing wheels... just because a standard or popular library was
written by a PC developer for x86 :(
I don't believe D can afford to be that short-sighted. The future is not
high performance x86 pc's, that time is _already_ 5 years behind us.

On 2013-04-08 10:15, Manu wrote:

> ... I don't think that's actually true. Can you suggest such a character
> in any language? I think they take that sort of thing into careful
> consideration when designing the codepoints for a character set.
> But if that is the case, then a function called toUpperInPlace is flawed
> by design, because it would be incapable of doing what it says it does.
> I'm not convinced that's true though.

The German double "s" (ß) in uppercase form should be "SS". That consists of two characters. There's also something similar with the Turkic "I" with a dot.

Here's the full list of special casings:

http://www.unicode.org/Public/UNIDATA/SpecialCasing.txt

You should also read this:

http://forum.dlang.org/thread/kcppa1$30b9$1@digitalmars.com

Shows some nasty corner cases with Unicode.

Short summary: encodings are PITA.

-- 
/Jacob Carlborg

On 2013-04-08 09:46, eles wrote:

> That kind of genericity will be just wonderful in some cases. For
> example, one could make sure, at compilation, that interrupt code does
> not call sleeping code when it comes to Linux kernel programming.
>
> I wonder, however, if one could re-define the notions of green/red
> several times in a project. Maybe per-module basis?

Of course. If I recall correctly you just annotate a type or similar:

struct ThreadSafe (T)
{
    T t;
}

void bar (ThreadSafe!(Foo) foo) { )

Now "bar" will only accept a thread safe "Foo".

-- 
/Jacob Carlborg

On 8 April 2013 19:06, Jacob Carlborg <doob@me.com> wrote:

> On 2013-04-08 10:15, Manu wrote:
>
>  ... I don't think that's actually true. Can you suggest such a character
>> in any language? I think they take that sort of thing into careful
>> consideration when designing the codepoints for a character set.
>> But if that is the case, then a function called toUpperInPlace is flawed
>> by design, because it would be incapable of doing what it says it does.
>> I'm not convinced that's true though.
>>
>
> The German double "s" (ß) in uppercase form should be "SS". That consists of two characters. There's also something similar with the Turkic "I" with a dot.
>
> Here's the full list of special casings:
>
> http://www.unicode.org/Public/**UNIDATA/SpecialCasing.txt<http://www.unicode.org/Public/UNIDATA/SpecialCasing.txt>
>
> You should also read this:
>
> http://forum.dlang.org/thread/**kcppa1$30b9$1@digitalmars.com<http://forum.dlang.org/thread/kcppa1$30b9$1@digitalmars.com>
>
> Shows some nasty corner cases with Unicode.
>
> Short summary: encodings are PITA.


... bugger! :/
Well I guess that function just needs to be amended to not-upper-case-ify
those troublesome letters? Shame.

On 2013-04-08 09:53, Dicebot wrote:

> Both blessing and curse of UDA's is that they are not part of type and
> thus mangling.

Can't you just annotate a type:

class Foo { }

struct ThreadSafe (T)
{
    T t;
}

ThreadSafe!(Foo) foo;

-- 
/Jacob Carlborg

On Monday, 8 April 2013 at 09:15:50 UTC, Jacob Carlborg wrote:
> On 2013-04-08 09:53, Dicebot wrote:
>
>> Both blessing and curse of UDA's is that they are not part of type and
>> thus mangling.
>
> Can't you just annotate a type:
>
> class Foo { }
>
> struct ThreadSafe (T)
> {
>     T t;
> }
>
> ThreadSafe!(Foo) foo;

Yes, and that allows some powerful stuff on its own, I am aware of it (and actually use sometimes). But a) it is not UDA ;) b) You are forced to make function templated to mark it as @nogc. Bad.

On 8 April 2013 18:56, Dicebot <m.strashun@gmail.com> wrote:

> On Monday, 8 April 2013 at 08:31:29 UTC, Manu wrote:
>
>> 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.
>>
>
> Yes, this is one of important steps in solution and some good work has been already done on topic. Main issue is that it won't be any convenient unless second step is done - making core language/compiler more friendly to embedded needs so that you can both implement custom druntime AND have solid language. Ability to track/prohibit GC allocations is one part of this. Static array literals is another. Most likely you'll also need to disable RTTI like it is done in C++/Embedded projects I have seen so far.
>
> I have done quite a research on this topic and have a lot to say here :)
>
>
>  'Really
>> embedded' software tends not to care so much about portability.
>> A bigger problem is D's executable size, which are rather 'plump' to be
>> frank :P
>> 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'.
>>
>
> Sure. Actually, executable size is an easy problem to solve considering custom druntimed mentioned before. Most of size in small executables come from statically linked huge druntime. (Simple experiment: use "-betterC" switch and compile hello-world program linking only to C stdlib. Same binary size as for C analog). Once you have defined more restrictive language subset and implemented minimal druntime for it, executable sizes will get better. Template issue is not an issue on their own, but D front-end is very careless about emitting template symbols (see my recent thread on topic). Most of them are weak symbols but hitting certain cases/bugs may bloat executable without you even noticing that.
>
> None of those issues is unsolvable show-stopper. But there does not seem an interest to work in this direction from current dmd developers (I'd be glad to be mistaken) and dmd source code sets rather hard entry barrier.
>

Yeah, I wish I had the time (or patience) to get involved at that level.
Breaking the ice in DMD seems daunting, and there's so many satellite jobs
I already can't find the time to work on (like std.simd).
I'd love to see a concerted push to solve these 2 key problems scheduled
and a just get them done some time...


You see, game developers are not the only ones with real-time requirements
> that are freaking tired of working with 40-year obsolete languages :) I am very interested in this topic. Looking forward to watching your DConf presentation recording about tricks used to adapt it to game engine by the way.
>

Oh god! Now there's expectation! >_<
Yeah... we'll see how that one goes.
I'm actually starting to worry I might not have as much exciting
experiences to share as people may be hoping... infact, I'm having quite a
lot of trouble making that talk seem interesting even to myself. My current
draft feels a bit thin. I hope it's not terrible! ;)

I think my biggest issue is that a slideshow is not a good place for
demonstrating code snippets, and it's hard to illustrate my approach
(particularly the curly bits) without showing a bunch of code... so I'll
end up just describing it maybe? I dunno.
Chances are you're just gonna hear a bunch of the same rants that
everyone's heard from me a bunch of times before :P

On 2013-04-08 10:31, Manu wrote:

> 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.
> A bigger problem is D's executable size, which are rather 'plump' to be
> frank :P
> 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'.

I agree with the templates, Phobos is full of them. Heck, I created a D-Objective-C bridge that resulted in a 60MB GUI Hello World exeuctable. Full of template and virtual methods bloat.

-- 
/Jacob Carlborg

On 8 April 2013 18:56, Dicebot <m.strashun@gmail.com> wrote:

> On Monday, 8 April 2013 at 08:31:29 UTC, Manu wrote:
>
>> 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.
>>
>
> Yes, this is one of important steps in solution and some good work has been already done on topic. Main issue is that it won't be any convenient unless second step is done - making core language/compiler more friendly to embedded needs so that you can both implement custom druntime AND have solid language. Ability to track/prohibit GC allocations is one part of this. Static array literals is another. Most likely you'll also need to disable RTTI like it is done in C++/Embedded projects I have seen so far.
>
> I have done quite a research on this topic and have a lot to say here :)


... so where's your dconf talk then? You can have one of my slots, I'm very interested to hear all about it! ;)

On 2013-04-08 10:56, Dicebot wrote:

> Sure. Actually, executable size is an easy problem to solve considering
> custom druntimed mentioned before. Most of size in small executables
> come from statically linked huge druntime. (Simple experiment: use
> "-betterC" switch and compile hello-world program linking only to C
> stdlib. Same binary size as for C analog).

That's cheating. It's most likely due to the C standard library is being dynamically linked. If you dynamically link with the D runtime and the standard library you will get the same size for a Hello World in D as in C. Yes, I've tried this with Tango back in the D1 days.

-- 
/Jacob Carlborg