Pure dynamic casts?

[Jeremie Pelletier]

language_fan wrote:
> Wed, 23 Sep 2009 10:43:53 -0400, Jeremie Pelletier thusly wrote:
> 
>> You're right about concurrency being a different concept than threading,
>>   but I wouldn't give threading away for a pure concurrent model either.
>> I believe D is aiming at giving programmers a choice of the tools they
>> wish to use. I could see uses of both a concurrent model with message
>> passing and a threading model with shared data used at once in a
>> program.
> 
> The danger in too large a flexibility is that concurrency is not easy and 
> it is getting incresingly complex. You need to be extraordinary good at 
> manually managing all concurrent use of data. If I may predict something 
> that is going to happen, it is that there will be high level models that 
> avoid many low level pitfalls. These models will not provide 100% 
> efficiency, but they are getting faster and faster, without compromizing 
> the safety aspect. This already happened with memory allocation (manual 
> vs garbage collection - in common applications, but not in special 
> cases). Before that we gave some of the error detection capabilities to 
> the compiler (e.g. we do not write array bounds checks ourselves 
> anymore). And optimizations (e.g. register allocation). You may disagree, 
> but I find it much more pleasant to find that the application does never 
> crash even though it works 15% slower than an optimal C++ code would.

15% slower is an extreme performance hit. I agree that code safety is 
useful and I use this model all the time for initialization and other 
code which isn't real time, but 15% takes away a lot of the 
application's responsiveness, if you have 50 such applications running 
on your system you just spent $1000 more in hardware to get the 
performance of entry level hardware with faster code.

If you wrote a real time renderer for example with that 15% hit, you get 
a very noticeable difference in framerate. Not to mention standard GUIs 
to be laggy on slower machines (just MSN messenger runs to a crawl on my 
old computer, yet it can run the first UT which does way more operations 
per second, because there's no performance hit by safer code bloat).

>> Shared data is always faster than message passing so you could
>> implement real time code with it, and use messsage passing for other
>> parts such as delegating GUI messages from the main loop.
> 
> Shared data is maybe faster on shared memory machines, but this is not a 
> fact in the general case.
 >
>> Shared data being harder to manage than message passing does not make it
>> a bad thing, it just means you can have two different models for two
>> different usages.
> 
> Shared data is not a single homogenous model. Things like transactional 
> memory work in shared memory systems, but still they have different 
> semantics.

Yes, I am well aware of that, I don't want to favor any particular 
design, I prefer to learn the semantics of a few of them and implement 
them all. Then I get the choice of the model to use depending on my needs.

Take search algorithm for example, you can pick between a binary search, 
b-tree r-tree, quadtree, octree, bsp, and a bunch of others along with 
dozens of variants of the ones mentionned depending on the data you're 
working with.

Its the same for concurrency, I can think of vector processing, 
functional calls, STM, message passing and shared memory off the top of 
my head. All being valid models with each their pros and cons, together 
forming a complete all-around solution.

Jeremie