www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D to ASM.js vs D to Dart (VM)

reply Etienne <etcimon gmail.com> writes:
Following my previous post about new opportunities for D with ASM.js, 
I've caught up with a lot of reading about Dart after seeing the 
seriousness of the project and a virtual machine being integrated to 
chrome directly. The benchmarks are already very promising[1]

My position has changed, and I now think D would be in a better position 
if it ran in the Dart VM. In other words, ASM.js has become the Dart 
language - the solution is to introduce a D to Dart compiler[2]. This 
compiler would be written in D with Pegged, the same way I'm writing 
this ASN.1 compiler[3]

This would require the interfaces from the Dart libraries (front-end DOM 
objects) to be built into a D library. Of course, the D=>Dart compiler 
would need to handle druntime and phobos as well for complete 
integration. I don't think this task is half as complicated as it would 
have been to go the D=>LLVM=>ASM.js route.

The best part of it all is this: you can compile the back-end 
(server-side) code to a binary executable using vibe.d and achieve 
immense performance improvements vs what runs in the Dart VM, and send 
the front-end code to Dart. This obviously seems like a durable and 
promising opportunity.

Comments?

[1] https://www.dartlang.org/performance/
[2] https://www.dartlang.org/articles/why-not-bytecode/#compiling-to-source
[3] https://github.com/globecsys/asn1.d
May 15 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Etienne:

 the solution is to introduce a D to Dart compiler[2]. This 
 compiler would be written in D with Pegged,

How much RAM is this going to use? Bye, bearophile
May 15 2014
parent Etienne <etcimon gmail.com> writes:
On 2014-05-15 4:48 PM, bearophile wrote:
 Etienne:

 the solution is to introduce a D to Dart compiler[2]. This compiler
 would be written in D with Pegged,

How much RAM is this going to use? Bye, bearophile

Good question, I'd be aiming for a 64 bit compiler with ~4 GB max memory usage, the ASN.1 compiler I made with pegged stayed well below 2 GB with 1000 lines of BNF->PEG rules unless I had 700+ lines of code to parse (which check every OR possibility at 3 levels deep for the longest matching solution). It's very efficient when you generate the grammar in a separate D file and make good use the garbage collector rather than mixin the grammar directly. https://github.com/globecsys/asn1.d/blob/master/asn1/parser/parser.d#L1022
May 15 2014
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 15 May 2014 at 20:34:31 UTC, Etienne wrote:
 My position has changed, and I now think D would be in a better 
 position if it ran in the Dart VM. In other words, ASM.js has 
 become the Dart language - the solution is to introduce a D to 
 Dart compiler[2].

Chrome runs pnacl which is a lot more efficient than Dart, but a D to Dart converter would be interesting for sharing code.
 Of course, the D=>Dart compiler would need to handle druntime 
 and phobos as well for complete integration.

That sounds like a bad idea. No sane person would write Dart code in D. The main benfit would be in sharing datastructures/RPC-like functionality.
May 15 2014
parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-15 4:58 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 That sounds like a bad idea. No sane person would write Dart code in D.
 The main benfit would be in sharing datastructures/RPC-like functionality.

The Phobos and druntime would most likely be type-resolved and inlined when converted to Dart code. It's mostly to stay in D. This compiler wouldn't really generate Dart code for... you know.. being "used". It would mostly allow to use the power of templates/alias/ctfe/contracts/auto/etc for browser-executed code (going through Dart is a side-effect)
May 15 2014
parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-15 5:10 PM, "Ola Fosheim Grøstad"
 Ok, as a Dart developer I would never use this:
 1a. The files will be too big.

There's really no issue with big files, because dart minify, tree shaking and the general VM caching opportunities & further optimizations can take care of it.
 1b. Compiling from D to Dart to JS will lead to insanely big files.

This compiler would be a bet that the VM can offer more and better optimizations. Tree shaking and minification can provide good advantages and refactoring opportunities for the time being, it's nothing we've never seen with the current JS libraries.
 2. The dart IDE has browser integrated debugging.

The dart code generated by D=>Dart compiler would be pretty-printed and suitable debugging through the dart IDE
 3. What is the benefit, it will be wiped out once PNaCl is available as
 a D backend?

The idea so far has been that the Dart VM will run on source code rather than bytecode like PNaCl, and it will be faster for it. First, you can further optimize the script if you're flexible on the data types. It's impossible to fit 2 longs into an int with PNaCl, but the Dart VM will do it if that could be something the source code allows. Second, you can keep doing "tree shaking" even during the program execution. Haven't used a part of the code for a while? Fine, lets just take it out of the memory and serialize the data for later. Finally, you keep the debug info with you in the browser. I don't know what the complexity of debugging bytecode in the browser would be, it's hard to come accross a good visual GDB debugger and we all know how long that's been around. So, this is mostly a bet that minified files pushed in a Dart VM will be better off than bytecode in most cases
May 15 2014
parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-15 6:04 PM, "Ola Fosheim Grøstad"
 It can do some tree shaking if you turn off metainfo. But D templates is
 bound to lead to bloat. Dart is a dynamic language and does not benefit
 much from templates. The power of Dart is in closures, but are you sure
 that D closures are compatible?

Templates are compile-time, a D compiler always takes care of all its compile-time duties =)
 Dart2js produce large files, acceptable performance, but big.

That's a temporary issue, I'm looking at years from now when/if Dart is more mature and implemented in more browsers as an alternative to javascript Also, I talked about caching in the VM http://1.bp.blogspot.com/-W1p7BELpIDE/UH42kXZeFsI/AAAAAAAANLA/kZGulTfNjQg/s1600/Screen+Shot+2012-10-16+at+9.39.29+PM.png
 Never. PNaCl will stay faster, it is IR based and multi threaded. Dart
 is a dynamic language designed to be JS compatible. The advantage with
 dart source distribution is in download size and future proof
 compatibility, not speed.

There's a lot of advantages to a source-code VM vs a bytecode VM. Javascript is compiled into a source-code VM, sure it'll never exceed the power of a byte-code VM because without more type information the optimization opportunities are limited See these benchmarks over time as an example: http://iq12.com/files/v8/v8_score.png Dart is still very young and does not benefit from as many optimizations for the moment. This same team (the V8 team) decided that a VM based on dynamic typing in a type-safe language would be better than pure bytecode because of adaptive and profile-guided optimizations. To me that's truly groundbreaking, and based on these charts - I'd trust them!
May 15 2014
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/15/2014 6:16 PM, Etienne wrote:
 This same team (the V8 team) decided that a VM based on dynamic typing
 in a type-safe language would be better than pure bytecode because of
 adaptive and profile-guided optimizations. To me that's truly
 groundbreaking, and based on these charts - I'd trust them!

Using bytecode doesn't prevent any of that.
May 15 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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. -- /Jacob Carlborg
May 15 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
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
May 18 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
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
May 18 2014
prev sibling parent Etienne <etcimon gmail.com> writes:
On 2014-05-16 2:14 AM, Paulo Pinto wrote:
 Only if you are speaking about V8, as the other VMs (Nashorn, Webkit,
 Gecko) do use bytecodes, multiple levels actually.

 --
 Paulo

Well it does need to be converted to bytecode at some point but my point is that there can be changes in the code's typing - Javascript is not typed so the dynamic typing is taken for granted but in a typed language it's an important decision to just switch over an 64 bit -> 8 bit dynamically depending on profiling, it has the potential to adjust instructions for branch prediction to succeed more and even carry more into the CPU registers for tight algorithms which (theoretically) would beat plain C with -O3 on intel compilers with an intel cpu =)
May 16 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 15 May 2014 at 21:05:12 UTC, Etienne wrote:
 On 2014-05-15 4:58 PM, "Ola Fosheim Grøstad" 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 The Phobos and druntime would most likely be type-resolved and 
 inlined when converted to Dart code. It's mostly to stay in D. 
 This compiler wouldn't really generate Dart code for... you 
 know.. being "used". It would mostly allow to use the power of 
 templates/alias/ctfe/contracts/auto/etc for browser-executed 
 code (going through Dart is a side-effect)

Ok, as a Dart developer I would never use this: 1a. The files will be too big. 1b. Compiling from D to Dart to JS will lead to insanely big files. 2. The dart IDE has browser integrated debugging. 3. What is the benefit, it will be wiped out once PNaCl is available as a D backend?
May 15 2014
prev sibling next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 15 May 2014 at 20:34:31 UTC, Etienne wrote:
 This compiler would be written in D with Pegged, the same way 
 I'm writing this ASN.1 compiler[3]

A lexer, parser, and set of AST classes for D already exists. You may want to use them instead. https://github.com/Hackerpilot/Dscanner/tree/master/std/d
May 15 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 15 May 2014 at 21:33:24 UTC, Etienne wrote:
 There's really no issue with big files, because dart minify, 
 tree shaking and the general VM caching opportunities & further 
 optimizations can take care of it.

It can do some tree shaking if you turn off metainfo. But D templates is bound to lead to bloat. Dart is a dynamic language and does not benefit much from templates. The power of Dart is in closures, but are you sure that D closures are compatible?
 1b. Compiling from D to Dart to JS will lead to insanely big 
 files.

This compiler would be a bet that the VM can offer more and better optimizations. Tree shaking and minification can provide good advantages and refactoring opportunities for the time being, it's nothing we've never seen with the current JS libraries.

Dart2js produce large files, acceptable performance, but big.
 The idea so far has been that the Dart VM will run on source 
 code rather than bytecode like PNaCl, and it will be faster for 
 it.

Never. PNaCl will stay faster, it is IR based and multi threaded. Dart is a dynamic language designed to be JS compatible. The advantage with dart source distribution is in download size and future proof compatibility, not speed.
May 15 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 15 May 2014 at 22:16:06 UTC, Etienne wrote:
 This same team (the V8 team) decided that a VM based on dynamic 
 typing in a type-safe language would be better than pure 
 bytecode because of adaptive and profile-guided optimizations. 
 To me that's truly groundbreaking, and based on these charts - 
 I'd trust them!

Yes, but not faster than a C-like IR. Still, you do get a non-intrusive GC, so in that sense it is a better option than PNaCl.
May 15 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 15 May 2014 at 22:16:06 UTC, Etienne wrote:
 On 2014-05-15 6:04 PM, "Ola Fosheim Grøstad"
 It can do some tree shaking if you turn off metainfo. But D 
 templates is
 bound to lead to bloat. Dart is a dynamic language and does 
 not benefit
 much from templates. The power of Dart is in closures, but are 
 you sure
 that D closures are compatible?

Templates are compile-time, a D compiler always takes care of all its compile-time duties =)
 Dart2js produce large files, acceptable performance, but big.

That's a temporary issue, I'm looking at years from now when/if Dart is more mature and implemented in more browsers as an alternative to javascript Also, I talked about caching in the VM http://1.bp.blogspot.com/-W1p7BELpIDE/UH42kXZeFsI/AAAAAAAANLA/kZGulTfNjQg/s1600/Screen+Shot+2012-10-16+at+9.39.29+PM.png
 Never. PNaCl will stay faster, it is IR based and multi 
 threaded. Dart
 is a dynamic language designed to be JS compatible. The 
 advantage with
 dart source distribution is in download size and future proof
 compatibility, not speed.

There's a lot of advantages to a source-code VM vs a bytecode VM. Javascript is compiled into a source-code VM, sure it'll never exceed the power of a byte-code VM because without more type information the optimization opportunities are limited

Only if you are speaking about V8, as the other VMs (Nashorn, Webkit, Gecko) do use bytecodes, multiple levels actually. -- Paulo
May 15 2014
prev sibling next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 15 May 2014 at 20:34:31 UTC, Etienne wrote:
 My position has changed, and I now think D would be in a better 
 position if it ran in the Dart VM.

Even if I _were_ a Chrome user, I'd have precisely zero interest in a browser monoculture. To wit, [P]NaCl and Dart effectively don't exist in my world. ASM.js is only slightly better in this regard because it at least _runs_ on other browsers. -Wyatt
May 16 2014
next sibling parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-16 9:12 AM, Chris wrote:
 I don't trust product / company centric software. It will lock you in or
 lock you out.

Google doesn't have a reputation of creating company centric software. SPDY was adopted by other browsers as well. If steam picks up on Dart, it could very well be adopted even by IE14 if that browser doesn't go the Netscape way ;)
May 16 2014
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
16-May-2014 17:21, Etienne пишет:
 On 2014-05-16 9:12 AM, Chris wrote:
 I don't trust product / company centric software. It will lock you in or
 lock you out.

Google doesn't have a reputation of creating company centric software. SPDY was adopted by other browsers as well. If steam picks up on Dart, it could very well be adopted even by IE14 if that browser doesn't go the Netscape way ;)

MS have TypeScript. Seems like everybody has their own favorite idea of better JavaScript. -- Dmitry Olshansky
May 16 2014
parent Etienne <etcimon gmail.com> writes:
On 2014-05-16 9:36 AM, Dmitry Olshansky wrote:
 16-May-2014 17:21, Etienne пишет:
 On 2014-05-16 9:12 AM, Chris wrote:
 I don't trust product / company centric software. It will lock you in or
 lock you out.

Google doesn't have a reputation of creating company centric software. SPDY was adopted by other browsers as well. If steam picks up on Dart, it could very well be adopted even by IE14 if that browser doesn't go the Netscape way ;)

MS have TypeScript. Seems like everybody has their own favorite idea of better JavaScript.

I'm guessing they'll have to make some browser plugins for each of those "better javascript"s just like we need to install perl/python/ruby to run them. Though I assume at that point there's going to be a "winning browser"
May 16 2014
prev sibling next sibling parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-16 9:45 AM, Chris wrote:
 You're kidding, aren't you. How can anything developed by a company
 become a real standard, catering for what developers need? The thread
 about Go not featuring generics is a good example. Look at what happened
 to Java. Market shares, strategic thinking, these all play into it, and
 don't forget the BIG EGOS you usually find among those who run those
 huge companies. Do you think that all decisions are made based on sound
 empirical evidence? Yeah, right.

You know the C programming language was pushed forward by AT&T right? And you know Google's SPDY is part of the HTML2 draft? I don't know what your opinions on the big corporate machines are, but some really smart software engineers and pioneers are being employed there with revolutionary ideas.
May 16 2014
next sibling parent Etienne <etcimon gmail.com> writes:
On 2014-05-16 9:52 AM, Etienne wrote:
 SPDY is part of the HTML2 draft

My bad I meant HTTP 2 ;)
May 16 2014
prev sibling next sibling parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-16 10:15 AM, Chris wrote:
 C isn't the best programming language. Only because something is
 everywhere, doesn't mean it's good (Windows comes to mind, and other big
 brands). As to the revolutionary ideas, are they really revolutionary or
 do they serve some corporate interest? Are there better ideas that will
 never be put into practice because they don't serve or even go against
 corporate interest? Is D still a small player because it is too
 community-oriented? (I hope this will never change!)

 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.

I'll have to go with: If it managed to serve corporate interest, that's because you were satisfied by it and suggested to others to "vote with their money". The company name is merely there to take that cash and re-distribute it to whom deserves it. I doubt the smartest person in the world could produce a microprocessor chip from sand without help
May 16 2014
next sibling parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-16 10:41 AM, Chris wrote:
 Isn't it sometimes just choosing the lesser evil instead of being able
 to choose something really good?

Alright, so you can try and make something really good and see if it can satisfy 95% of the world's offices as much. Even with infinite funds and teammates, chances are you'll quickly end up admiring that "dreadful Microsoft"'s employees for putting up with that shit and making something good out of it.. whatever the salary. Companies don't make humans miserable; humans make humans miserable. Hatred for humans because they serve other humans under a banner is just plain ignorance
May 16 2014
parent Etienne <etcimon gmail.com> writes:
On 2014-05-16 10:57 AM, Chris wrote:
 And companies are run by humans, if I'm not completely mistaken. It's
 not the army that kills people, it's the humans in the army that kill
 other humans. Stoutly reasoned!

 Hatred for humans because they serve other humans under a banner is
 just plain ignorance

Who's talking about hatred? Being skeptical doesn't involve hatred. The thing is that the best engineers cannot put their ideas into practice, if the company rejects it for whatever reason (there are so many, partly highly ridiculous, reasons why good ideas have been rejected, one could write a book about it). And yes, if humans serve under a banner, you have the right to criticize them, because they accept the banner and what it stands for. The fact that we all have to serve somebody to put food on our tables, doesn't mean it is right.

I think we're both right, just arguing about the risks of both extremities of the evilness scale in companies. They can be really good, and really bad. Break down those too big to fail more power to the people etc. etc.
May 16 2014
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/2014 10:41 AM, Chris wrote:
 On Friday, 16 May 2014 at 14:20:36 UTC, Etienne wrote:
 I'll have to go with: If it managed to serve corporate interest,
 that's because you were satisfied by it and suggested to others to
 "vote with their money".

... or because nobody ever had a real choice

...or because fools are plentiful and easily swayed by theatrics, popularity, gimmicks, projected image and other such easily-manipulated and fabricated idiocy. There's all sorts of reasons why the whole "voting with their wallets" thing is a complete and total fantasy.
May 16 2014
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 16.05.2014 21:53, schrieb Joakim:
 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?

No, when compared against what Symbian OS could do with less resources.
May 16 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/2014 4:10 PM, Paulo Pinto wrote:
 Am 16.05.2014 21:53, schrieb Joakim:
 Why isn't iOS good?

No, when compared against what Symbian OS could do with less resources.

I don't know what the hardware was like on Symbian's short-lived touch-screen stuff, but heck, PalmOS ran beautifully on a 16MHz Dragonball with 8MB RAM (and yea, those are "M"s, not "G"s), let alone the later ARM-based Palms. (I loved my Visor Deluxe and Zire 71 :) )
May 17 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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. (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.)
 Nick may not believe in people voting with their wallets,

Well, to be clear (and without trying to get too political about it), I do believe in *attempting* to vote with one's wallet, and that it can be a *factor* in what succeeds and what doesn't. I just don't believe it's remotely close to being the sole primary factor or that it remotely implies "what succeeds must therefore be good". And I think all that's unfortunate.
May 17 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
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
May 17 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, May 16, 2014 at 03:20:33PM +0000, Chris via Digitalmars-d wrote:
[...]
 Yep. Look at the open source communities, all the forks and fights.
 There used to be Tango vs Phobos. On the other hand, it's good that
 people can just do their own thing, if they're not happy with an
 existing project (for what ever reason). With companies, you have to
 stick with whatever decision they make, you ain't got no choice there.
 I remember that Apple removed my development tools after an upgrade
 and I had to download them again through the AppStore (had to register
 etc.). That was it for me. Good night! I'm on ArchLinux now. Never
 looked back.

Yeah, the thing with open source is that if you don't like something, you have the right and the ability to go and change it yourself. With proprietary software, you're out of luck. The most you can do is to submit a bug report and pray that they will fix it soon, hopefully in the next release, which is probably months or perhaps years away. I remember one time there was a nasty Phobos bug that was a showstopper for one of my projects. I needed the fix right away, since it was critical to the project, and judging by the track record of D bugfixes, it may take months before somebody notices the issue in bugzilla. Well, no problem, just checkout git HEAD, find the offending code, add a temporary fix to it. Then I can happily resume my project without worrying too much, until the "official" fix is merged. With a proprietary product, usually you don't even get to *see* their bugtracker, much less dig into the code and fix it yourself. Your project gets stuck with imperfect workarounds that only works sometimes, and you have to uglify your code which becomes a maintenance nightmare down the road. If Phobos had been a proprietary product, I would've given up D and moved on to something else. T -- There are two ways to write error-free programs; only the third one works.
May 16 2014
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/2014 9:21 AM, Etienne wrote:
 On 2014-05-16 9:12 AM, Chris wrote:
 I don't trust product / company centric software. It will lock you in or
 lock you out.

Google doesn't have a reputation of creating company centric software. SPDY was adopted by other browsers as well. If steam picks up on Dart, it could very well be adopted even by IE14 if that browser doesn't go the Netscape way ;)

Google's reputation hasn't very well matched it's reality for quite some time. They basically don't give much more of a rat's ass about standards and compatibility than MS these days. Even Gmail's alleged "POP3" feature works in bizarre non-POP3 ways. If they don't even give half a shit about making something as basic and standard as POP3 behave like it's supposed to, how can anything that's much more heavily Google-based be trusted long-term? Even if NaCl/Dart/whatever do wind up in all the other browsers, the modern-day Google would be prone to making goofy arbitrary changes to their version on a whim, with or without reasonable justification. It's just how Google is these days. They're not the cute little upstart they were 15 years ago. They're a 600lb gorilla now, they full well know it, and they're not afraid to use that to pull whatever they feel like. "Don't be evil" my ass. It's not as if that was ever setting a very high bar in the first place.
May 16 2014
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.

May 17 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 16 May 2014 at 12:55:30 UTC, Wyatt wrote:
 On Thursday, 15 May 2014 at 20:34:31 UTC, Etienne wrote:
 My position has changed, and I now think D would be in a 
 better position if it ran in the Dart VM.

Even if I _were_ a Chrome user, I'd have precisely zero interest in a browser monoculture. To wit, [P]NaCl and Dart effectively don't exist in my world. ASM.js is only slightly better in this regard because it at least _runs_ on other browsers. -Wyatt

See my post: http://forum.dlang.org/thread/lktk12$15u1$3 digitalmars.com?page=3#post-qjxnftlafeeaskifcefd:40forum.dlang.org I don't trust product / company centric software. It will lock you in or lock you out.
May 16 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 16 May 2014 at 13:21:22 UTC, Etienne wrote:
 On 2014-05-16 9:12 AM, Chris wrote:
 I don't trust product / company centric software. It will lock 
 you in or
 lock you out.

Google doesn't have a reputation of creating company centric software. SPDY was adopted by other browsers as well. If steam picks up on Dart, it could very well be adopted even by IE14 if that browser doesn't go the Netscape way ;)

You're kidding, aren't you. How can anything developed by a company become a real standard, catering for what developers need? The thread about Go not featuring generics is a good example. Look at what happened to Java. Market shares, strategic thinking, these all play into it, and don't forget the BIG EGOS you usually find among those who run those huge companies. Do you think that all decisions are made based on sound empirical evidence? Yeah, right.
May 16 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 16 May 2014 at 12:55:30 UTC, Wyatt wrote:
 Even if I _were_ a Chrome user, I'd have precisely zero 
 interest in a browser monoculture.  To wit, [P]NaCl and Dart 
 effectively don't exist in my world.

Dart compiles to JS, but drops support for IE9 after this summer… so it isn't a mono culture, but you do depend on Google strategic planning by using Dart.
 ASM.js is only slightly better in this regard because it at 
 least _runs_ on other browsers.

Yes, that's a good quality. You also have Google Closure which is type annotated JS that does optimization/minification.
May 16 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 16 May 2014 at 13:52:37 UTC, Etienne wrote:
 On 2014-05-16 9:45 AM, Chris wrote:
 You're kidding, aren't you. How can anything developed by a 
 company
 become a real standard, catering for what developers need? The 
 thread
 about Go not featuring generics is a good example. Look at 
 what happened
 to Java. Market shares, strategic thinking, these all play 
 into it, and
 don't forget the BIG EGOS you usually find among those who run 
 those
 huge companies. Do you think that all decisions are made based 
 on sound
 empirical evidence? Yeah, right.

You know the C programming language was pushed forward by AT&T right? And you know Google's SPDY is part of the HTML2 draft? I don't know what your opinions on the big corporate machines are, but some really smart software engineers and pioneers are being employed there with revolutionary ideas.

C isn't the best programming language. Only because something is everywhere, doesn't mean it's good (Windows comes to mind, and other big brands). As to the revolutionary ideas, are they really revolutionary or do they serve some corporate interest? Are there better ideas that will never be put into practice because they don't serve or even go against corporate interest? Is D still a small player because it is too community-oriented? (I hope this will never change!) 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.
May 16 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 16 May 2014 at 14:20:36 UTC, Etienne wrote:
 On 2014-05-16 10:15 AM, Chris wrote:
 C isn't the best programming language. Only because something 
 is
 everywhere, doesn't mean it's good (Windows comes to mind, and 
 other big
 brands). As to the revolutionary ideas, are they really 
 revolutionary or
 do they serve some corporate interest? Are there better ideas 
 that will
 never be put into practice because they don't serve or even go 
 against
 corporate interest? Is D still a small player because it is too
 community-oriented? (I hope this will never change!)

 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.

I'll have to go with: If it managed to serve corporate interest, that's because you were satisfied by it and suggested to others to "vote with their money".

... or because nobody ever had a real choice (Windows comes to mind again). Talking about creating monopolies, cartels and the like. This goes for everything, not just software. Do people learn English, because they think it is a beautiful language or because they have to, if they want to access a global market? Does the omnipresence of English mean that it's the best language ever (Bien sûr!) and that's why people "vote" for it? Isn't it sometimes just choosing the lesser evil instead of being able to choose something really good?
 The company name is merely there to take that cash and 
 re-distribute it to whom deserves it. I doubt the smartest 
 person in the world could produce a microprocessor chip from 
 sand without help

May 16 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 16 May 2014 at 14:46:43 UTC, Etienne wrote:
 On 2014-05-16 10:41 AM, Chris wrote:
 Isn't it sometimes just choosing the lesser evil instead of 
 being able
 to choose something really good?

Alright, so you can try and make something really good and see if it can satisfy 95% of the world's offices as much. Even with infinite funds and teammates, chances are you'll quickly end up admiring that "dreadful Microsoft"'s employees for putting up with that shit and making something good out of it.. whatever the salary.

 Companies don't make humans miserable; humans make humans 
 miserable.

And companies are run by humans, if I'm not completely mistaken. It's not the army that kills people, it's the humans in the army that kill other humans. Stoutly reasoned!
 Hatred for humans because they serve other humans under a 
 banner is just plain ignorance

Who's talking about hatred? Being skeptical doesn't involve hatred. The thing is that the best engineers cannot put their ideas into practice, if the company rejects it for whatever reason (there are so many, partly highly ridiculous, reasons why good ideas have been rejected, one could write a book about it). And yes, if humans serve under a banner, you have the right to criticize them, because they accept the banner and what it stands for. The fact that we all have to serve somebody to put food on our tables, doesn't mean it is right.
May 16 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 16 May 2014 at 15:02:42 UTC, Etienne wrote:
 On 2014-05-16 10:57 AM, Chris wrote:
 And companies are run by humans, if I'm not completely 
 mistaken. It's
 not the army that kills people, it's the humans in the army 
 that kill
 other humans. Stoutly reasoned!

 Hatred for humans because they serve other humans under a 
 banner is
 just plain ignorance

Who's talking about hatred? Being skeptical doesn't involve hatred. The thing is that the best engineers cannot put their ideas into practice, if the company rejects it for whatever reason (there are so many, partly highly ridiculous, reasons why good ideas have been rejected, one could write a book about it). And yes, if humans serve under a banner, you have the right to criticize them, because they accept the banner and what it stands for. The fact that we all have to serve somebody to put food on our tables, doesn't mean it is right.

I think we're both right, just arguing about the risks of both extremities of the evilness scale in companies. They can be really good, and really bad. Break down those too big to fail more power to the people etc. etc.

Yep. Look at the open source communities, all the forks and fights. There used to be Tango vs Phobos. On the other hand, it's good that people can just do their own thing, if they're not happy with an existing project (for what ever reason). With companies, you have to stick with whatever decision they make, you ain't got no choice there. I remember that Apple removed my development tools after an upgrade and I had to download them again through the AppStore (had to register etc.). That was it for me. Good night! I'm on ArchLinux now. Never looked back.
May 16 2014
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 16 May 2014 at 14:03:05 UTC, Ola Fosheim Grøstad wrote:
 Dart compiles to JS, but drops support for IE9 after this 
 summer… so it isn't a mono culture, but you do depend on Google 
 strategic planning by using Dart.

doing so. Belay that, if I wanted a compiler centipede, I'd be more interested in targeting Haxe: community-driven and it lets me _also_ target C#, JVM, and a number of other silly things. -Wyatt
May 16 2014
prev sibling next sibling parent "Joakim" <dlang joakim.airpost.net> writes:
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?
May 16 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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, but you also get working closures, this-pointer etc.
 Belay that, if I wanted a compiler centipede, I'd be more 
 interested in targeting Haxe: community-driven and it lets me

I like the concept, but it takes a lot of resources to cover browser bugs. Dart targets current browsers and are tested against them. It provides polyfills where the browser is lacking and gives you booleans to test for features. You have to count in the libraries, IDE, debugger etc.
May 16 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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).
May 17 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
May 18 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
May 18 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
May 18 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
May 18 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
May 19 2014
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 19 May 2014 at 18:05:29 UTC, Dicebot wrote:
 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.

Comparing assemble at link time is an option. Comparing IR is another (LLVM does this).
May 19 2014