Pure dynamic casts?

[language_fan]

Thu, 24 Sep 2009 20:46:13 -0400, Jeremie Pelletier thusly wrote:

> 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.

The cost of e.g. doubling computing power depends on the domain. If you 
are building desktop end user applications, they usually should scale 
from single core atoms to 8-core high-end enthusiastic game computers. So 
the cpu requirements shouldn't usually be too large. Usually even most of 
the 1-3 previous generations' hardware runs them just nicely.

Now doubling the cpu power of a low-end current generation PC does not 
cost $1000, but maybe $20-50. You can continue this until the cpu costs 
about $400-500. By then you've achieved at least tenfold speedup. On the 
gpu market the cheapest chips have very limited capabilities. You can buy 
5 times faster graphics cards for $50-60. $150-160 will get you a 25 
times faster gpu than the first one. 4..8 GB RAM is also really cheap 
these days, and so is a 1.5 TB hard drive. Hardly any desktop program 
requires that much from the hardware. The 15% or even 50% slower 
execution speed seems rather small a problem when you can avoid it by 
buying faster hardware. Hardly any program is cpu bound, not even the 
most demanding games are.

On the server side many systems use php which is both unsafe and slow. If 
you have decent load balancing and cache systems, it does not even matter 
since the system may not be cpu bound, either. Even top10 popular sites 
like wikipedia run on slow php.