A Perspective on D from game industry

via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 17 11:08:57 PDT 2014


On Tuesday, 17 June 2014 at 17:19:25 UTC, H. S. Teoh via
Digitalmars-d wrote:
> The halting problem is equivalent to Kolgomorov complexity, 
> which in
> turn relates to optimal compression, which has applications in 
> global
> optimization problems in compiler technology. Sure, the way some
> textbooks present it, it's just an obscure academic exercise, 
> but it
> does have far-reaching implications.

I don't understand why, since in compiler optimization you almost 
always just aim for best effort.

> can take on any level of complexity up to the halting problem, 
> so many of them are intractible to automate.

Well, but in that case they are also intractible for human
beings. Or brains can be simulated in finite space/time IMO.

> That depends on your specific application. There are 
> applications for
> which the whole point *is* to find the optimal solution. I 
> don't think
> you can simply write off the whole thing as "unnecessary".

In games, most certainly. In fact, the games AI has to be dumbed 
down and made emotionally interesting instead.

> Some forms of code translation may very well be NP-complete, or 
> worse.

Sure. But they are only NP-complete if you are dealing with an
infinite dimension. The moment all dimensions are finite (bounded 
by a constant) the
problem is most certainly P? Of course, P can be terrible in 
terms of performance. So it says little.

What complexity is good for is aiding strategies when doing 
algorithm design. What it is not good for is preventing 
exploration of algorithms. You can often get good results for 
computationally intensive problems using randomization/stochastic 
strategies.

> Like running global optimization on a set of mutually-recursive
> functions. And some instances of optimal register allocation, 
> IIRC.

You almost never want optimal, you want to balance off resource
usage with what you gain.

> There's no need to get rid of string mixins just because of 
> that 1% of
> code that actually needs to use them. Nobody says that the
> transformation must work on 100% of all D programs, otherwise 
> we can't
> have it at all.

The language should guarantee that you can detect deprecated
features with 100% certainty. Otherwise you risk distributing
template-libraries that don't work for certain configurations.

If you want to reduce the deployed code size you might want to
translate code into something that can be transferred fast to
web-browsers. That means you have to be able to translate 100%.

Of course, it is possible to avoid string mixins, but the same
holds for #define(x…) in CPP.


More information about the Digitalmars-d mailing list