Slow performance compared to C++, ideas?

[Andrei Alexandrescu]

On 6/7/13 3:42 AM, Walter Bright wrote:
> On 6/6/2013 10:14 PM, Andrei Alexandrescu wrote:
>> I don't buy all that "humans aren't rational" stuff.
>
> I don't either, but I don't think that was my point.
>
> My point is that a language where -O delivers the performance is
> preferable to a language that you have to do careful annotations and run
> extra tools on to get it.
>
> We discussed a while back an experimental Java compiler where
> annotations were used to signify uniqueness, etc. The compiler was a
> technical success, but the researcher was not very successful in getting
> users to use the annotations.
>
> This is why I am pushing for D doing attribute inference as much as
> possible, rather than expecting people to annotate carefully. I believe
> we are much more likely to be successful with the former approach.
>
> I'd very much prefer an auto-finalize mechanical solution.
>
> BTW, dustmite and rdmd are great tools. I'm happy to have been proven
> wrong about them.

The more I think of this the more I regress toward my initial opinion: 
just let it be. I understand the arguments involved and it is my opinion 
that the problem is overstated (it's just a default, not something that 
prevents people from doing what they want to do), the benefits are 
exaggerated (we're not going to see whopping performance improvements), 
and the costs are underplayed (let's not forget that many breaking 
changes look great _before_ the breakage).

We need to think holistically. If improving performance of generated 
code is a goal of ours, then there are so many better, nonbreaking 
vehicles for that: the backend interface, the inliner, the GC, the 
standard library, the SIMD builtins and associated library code, and 
many many more low-hanging fruit of lesser disruption and better returns.


Andrei