On 5/16/2014 4:16 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Friday, 16 May 2014 at 15:54:44 UTC, Wyatt wrote:
>> As I understand it, you take a substantial performance hit for doing so.
>
> I haven't noticed this much. It is a bit more annoying to debug on IE. I
> doubt you get much more than a 40% penalty,

That's a pretty big penalty for something that's already so slow.

> but you also get working
> closures, this-pointer etc.

Am 17.05.2014 20:12, schrieb Nick Sabalausky:
> On 5/16/2014 3:53 PM, Joakim wrote:
>> On Friday, 16 May 2014 at 14:15:20 UTC, Chris wrote:
>>> Mind you, how many of the big "be all end all"-technologies that have
>>> been hyped over the years are really good (including community base
>>> projects)? JS, Java, Ajax, PHP, Ruby, iOS, Android ...? With good I
>>> mean really good, not omnipresent.
>>
>> Agree with you on all of those, except for iOS.  I know many of us hate
>> how much its success is driven by marketing, but it appears to be a very
>> solid product technically.  At least that's what I read, I haven't
>> bought an Apple product in a decade because of their crazy stance on
>> patents and how closed they've become.
>>
>> However, just looking at iOS technically, even the latest iPad Air and
>> iPhone 5s run on just 1 GB of RAM and still regularly outperform Android
>> devices, which is crazy considering Android superphones/tablets have up
>> to 3 GBs of RAM these days.  iOS devices repeatedly benchmark as the
>> least laggy for touch.  Nick may not believe in people voting with their
>> wallets, but iOS devices have garnered Apple a couple hundred billion in
>> profits so far:
>>
>> http://www.phonearena.com/news/Samsung-and-Apple-reportedly-earned-87.9-of-the-smartphone-market-profits-for-the-last-6-years_id54030
>>
>>
>>
>> I suppose you can hate on Obj-C, but that's not really iOS.  The latest
>> release got bogged down in all the bling, but that's more like Apple
>> heaped too much icing on top: the cake is still great.
>>
>> Why isn't iOS good?
>
> The problem with iOS devices isn't software bloat, it's overall design
> and, as you mentioned, Apple's...uhh...orwellian-ness. (IMO, anyway) I
> could go on and on and on about iPhone's design problems (and have done
> so ;) )
>
> And I'm not surprised Android is a little slower/laggier than iOS, what
> with Dalvik. I don't care how much they've optimized it, a JVM-alike at
> the system-level on a mobile device is just asking for "second-place at
> best" (performance-wise anyway). They're now forced to go out of their
> way with stuff like ART just to mitigate some of the problems Dalvik
> introduced. That's the one big thing I *do* think Apple really got right
> - native system-level with ARC, instead of mobile JVM clone.

They haven't. That is the whole point.

It is well known among Java developers with Android experience, that Dalvik is a kind of good enough implementation, without much effort. Almost as a modern BASIC.

It only had improvements on 2.2 (got a JIT), 2.3 (small improvements and a little bette GC) and 4.3 (a few more intrisics).

The original Dalvik architect is no longer in the team.

I am waiting eagerly for the Google IO ART session to see how the new AOT compiler behaves. Specially when compared with MIDL .NET compilers.

>
> (FWIW/BTW, MS has actually hit a rather interesting middle-ground with
> WinRT's sort-of-a-VM-but-not-exactly approach. Not that I'm a fan of
> Win8/WinRT/Metro/MS/etc, but that particular aspect is quite noteworthy
> IMO.)
>

They basically implemented the original model of .NET. Based on the available documentation, COM+ VOS as it was called is quite similar to WinRT. Then Java happenend, and another design approach was done.

From the MSDN blogs, it seems the native side has been getting strong since the Longhorn failure, which lead to WinRT, RyuJIT, .NET Native and stronger focus on C++. This is my opinion, not sure how well it
matches reality.

--
Paulo

On Saturday, 17 May 2014 at 18:25:00 UTC, Nick Sabalausky wrote:
> On 5/16/2014 4:16 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> On Friday, 16 May 2014 at 15:54:44 UTC, Wyatt wrote:
>>> As I understand it, you take a substantial performance hit for doing so.
>>
>> I haven't noticed this much. It is a bit more annoying to debug on IE. I
>> doubt you get much more than a 40% penalty,
>
> That's a pretty big penalty for something that's already so slow.

Hm, I think it is roughly 40% slower than Dart, but perhaps 10% slower than JS, and sometimes faster than JS (probably because of type info).

On Friday, 16 May 2014 at 06:46:08 UTC, Jacob Carlborg wrote:
> On 16/05/14 00:16, Etienne wrote:
>
>> Templates are compile-time, a D compiler always takes care of all its
>> compile-time duties =)
>
> Unfortunately it does not. It causes unnecessary bloat. Take this for example:
>
> void foo (T) (T t);
>
> foo(new Foo);
> foo(new Bar);
>
> This will generate two functions, even though the machine code is exactly the same for both.

If the machine code is the same, the function can be merged by the optimizer.

deadalnix:

> If the machine code is the same, the function can be merged by the optimizer.

But in general isn't it more efficient to not generate bloat instead of generating it, detecting it, and removing it?

Bye,
bearophile

Am 18.05.2014 10:02, schrieb bearophile:
> deadalnix:
>
>> If the machine code is the same, the function can be merged by the
>> optimizer.
>
> But in general isn't it more efficient to not generate bloat instead of
> generating it, detecting it, and removing it?
>
> Bye,
> bearophile

Which you can only do if the compiler can see the whole code.

It doesn't work in binary libraries.

--
Paulo

Paulo Pinto:

> Am 18.05.2014 10:02, schrieb bearophile:
>> But in general isn't it more efficient to not generate bloat instead of
>> generating it, detecting it, and removing it?
>>
>> Bye,
>> bearophile
>
> Which you can only do if the compiler can see the whole code.
>
> It doesn't work in binary libraries.

I think in this case avoiding part of the problem is better than avoiding none of it :-) There are other similar situations where avoiding the template bloat is useful. This generates two instances of doubleIt in the binary:


T doubleIt(T)(T x) { return x * 2; }
void main() {
    immutable r1 = doubleIt(10);
    immutable r2 = doubleIt(cast(const int)10);
}


The asm, from DMD:

_D4temp15__T8doubleItTiZ8doubleItFNaNbNiNfiZi:
        enter   4,0
        add EAX,EAX
        leave
        ret

_D4temp16__T8doubleItTxiZ8doubleItFNaNbNiNfxiZxi:
        enter   4,0
        add EAX,EAX
        leave
        ret

Bye,
bearophile

Am 18.05.2014 10:18, schrieb bearophile:
> Paulo Pinto:
>
>> Am 18.05.2014 10:02, schrieb bearophile:
>>> But in general isn't it more efficient to not generate bloat instead of
>>> generating it, detecting it, and removing it?
>>>
>>> Bye,
>>> bearophile
>>
>> Which you can only do if the compiler can see the whole code.
>>
>> It doesn't work in binary libraries.
>
> I think in this case avoiding part of the problem is better than
> avoiding none of it :-) There are other similar situations where
> avoiding the template bloat is useful. This generates two instances of
> doubleIt in the binary:
>
>
> T doubleIt(T)(T x) { return x * 2; }
> void main() {
>      immutable r1 = doubleIt(10);
>      immutable r2 = doubleIt(cast(const int)10);
> }
>
>
> The asm, from DMD:
>
> _D4temp15__T8doubleItTiZ8doubleItFNaNbNiNfiZi:
>          enter   4,0
>          add EAX,EAX
>          leave
>          ret
>
> _D4temp16__T8doubleItTxiZ8doubleItFNaNbNiNfxiZxi:
>          enter   4,0
>          add EAX,EAX
>          leave
>          ret
>
> Bye,
> bearophile


Right, but what about more complex examples with nested templates, mixins and inlining?

At what moment does the optimizer give up and passes the work down to the linker?

Usually the work is done on basic block level, it doesn't have the full picture.

There are a few interesting talks from LLVM where Chandler Carruth shows how pages of code can be generated out of innocent looking code, because of nested calls.

--
Paulo

On Sunday, 18 May 2014 at 08:02:59 UTC, bearophile wrote:
> deadalnix:
>
>> If the machine code is the same, the function can be merged by the optimizer.
>
> But in general isn't it more efficient to not generate bloat instead of generating it, detecting it, and removing it?
>
> Bye,
> bearophile

Yes, that is not the most efficient way :D Hopefully, this can be done AOT so that is ok.

On Sunday, 18 May 2014 at 08:02:59 UTC, bearophile wrote:
> deadalnix:
>
>> If the machine code is the same, the function can be merged by the optimizer.
>
> But in general isn't it more efficient to not generate bloat instead of generating it, detecting it, and removing it?
>
> Bye,
> bearophile

It is much more difficult task I believe as template bodies can change dramatically even from a slightest change in parameter types. Compiler needs to prove instance equivalence in some way to do this which sounds harder than just comparing result assembly.