Duetto: a C++ compiler for the Web going beyond Emscripten and Node.js • Hacker News Board

Re: Duetto: a C++ compiler for the Web going beyond Emscripten and Node.js

#51

Post by angersock » Thu, Oct 31, 2013, 4:39 PM UTC

flohofwoe wrote: post #43

angersock wrote: post #34

Earlier quoted context omitted.

Downvoting comes around 500 maybe? Not actually sure. Anyways, lest you think my observation is just a "non-constructive comment": The great thing about the browser is that it is free of a lot of garbage we have to deal with in C++. The antics required to make C++ work in the browser, while laudable, are absurd. If you need cross-platform code, write in Java and avoid native extensions. If you need cross-platform cod…

Have you ever had to maintain a code base with more then a few hundred thousand lines of code across Flash, Javascript, iOS, Android, PC, OSX, Xbox, PS, Wii, Vita, NintendoDS, ...and whatever other gaming platform is popular at the moment? The "popular platform of the day" changes a lot faster then being able to write new code for it. You need to support that new platform within 3 months or less. Good luck rewriting…

http://fabiensanglard.net/anotherWorld_code_review/index.php

This was well-solved a long time ago so...uh...yeah I guess? With much worse hardware?

Maybe Lua?

Do you actually have a real example, or were you just listing off all the magical platforms?

EDIT:

Ha, you do some pretty cool work.

Anyways, put more mildly, is there a case you've seen where you actually have to support all the platforms you've mentioned?

(I seem to be making all sorts of friends today. :| )

Re: Duetto: a C++ compiler for the Web going beyond Emscripten and Node.js

#52

Post by tomkludy » Thu, Oct 31, 2013, 4:48 PM UTC

flohofwoe wrote: post #43

angersock wrote: post #34

Earlier quoted context omitted.

Downvoting comes around 500 maybe? Not actually sure. Anyways, lest you think my observation is just a "non-constructive comment": The great thing about the browser is that it is free of a lot of garbage we have to deal with in C++. The antics required to make C++ work in the browser, while laudable, are absurd. If you need cross-platform code, write in Java and avoid native extensions. If you need cross-platform cod…

Have you ever had to maintain a code base with more then a few hundred thousand lines of code across Flash, Javascript, iOS, Android, PC, OSX, Xbox, PS, Wii, Vita, NintendoDS, ...and whatever other gaming platform is popular at the moment? The "popular platform of the day" changes a lot faster then being able to write new code for it. You need to support that new platform within 3 months or less. Good luck rewriting…

Frankly, I've had to maintain a huge C++-only codebase, and that's why I hope to never write another app in C++.

Yours is an argument for a high-level, typesafe, compiled-to-native and compiled-to-javascript language. But IMO the argument falls down when applied to C++, because it is not high-level, it is only marginally typesafe, and it doesn't compile to javascript well at all (tradeoff of either massive performance, or missing basic functionality like 64 bit ints).

It is very possible that no language will fit this role exactly for some time to come. But, to me at least, it is very clear that C++ is NOT the language for the job.

Re: Duetto: a C++ compiler for the Web going beyond Emscripten and Node.js

#53

Post by dman » Thu, Oct 31, 2013, 4:52 PM UTC

betterunix wrote: post #38

dman wrote: post #22

Earlier quoted context omitted.

I like C++ because it addresses problems relevant for building performant applications in the real world. Details matter for performance - the memory hierarchy, cost of small allocations, allocating and accessing aligned data, copying to enable concurrency are all real things.

Details may matter for performance (though in my experience people tend to gravitate towards such things while ignoring asymptotic improvements that can be far more dramatic), but C++ is annoying even if that is something you are trying to do. C++ has a tendency to insert "surprises" into compiled code -- lots of implicit function calls, copies, etc. I saw this sort of thing first-hand when I TA'd a data structures c…

The C++ philosophy is to only pay for costs of things that you actually use. Making every check in -Wall an error by default would make every one pay the costs of those extra checks at compile time.

Re: Duetto: a C++ compiler for the Web going beyond Emscripten and Node.js

#54

Post by flohofwoe » Thu, Oct 31, 2013, 4:53 PM UTC

angersock wrote: post #51

flohofwoe wrote: post #43

Earlier quoted context omitted.

Have you ever had to maintain a code base with more then a few hundred thousand lines of code across Flash, Javascript, iOS, Android, PC, OSX, Xbox, PS, Wii, Vita, NintendoDS, ...and whatever other gaming platform is popular at the moment? The "popular platform of the day" changes a lot faster then being able to write new code for it. You need to support that new platform within 3 months or less. Good luck rewriting…

http://fabiensanglard.net/anotherWorld_code_review/index.php This was well-solved a long time ago so...uh...yeah I guess? With much worse hardware? Maybe Lua? Do you actually have a real example, or were you just listing off all the magical platforms? EDIT: Ha, you do some pretty cool work. Anyways, put more mildly, is there a case you've seen where you actually have to support all the platforms you've mentioned? (I…

;) We've been an independent dev studio (Radon Labs) before being bought by Bigpoint, and the only way to survive was to support a wide range of platforms (we weren't big or successful enough to have the luxury to pick our target platforms). So our engine basically scaled from the NintendoDS to PCs. Being able today to just cross-compile our engine to JS+WebGL or mobile platforms(between 150k and 500k of C++ code, depending what modules you link) is very nice. Plus, for browser games, Flash and plugins as a whole are on the way out, so we need a solution to bring our games into the browser without plugins. A solution like emscripten or duetto to compile C++ (or maybe later other languages) to JS with a relatively small (and predictable!) performance hit is definitely "good enough" for us.

Re: Duetto: a C++ compiler for the Web going beyond Emscripten and Node.js

#55

Post by angersock » Thu, Oct 31, 2013, 5:09 PM UTC

protomyth wrote: post #47

angersock wrote: post #37

Earlier quoted context omitted.

Only the good parts: http://www.amazon.com/C-Programming-Language-2nd-Edition/dp/...

What an amazingly unhelpful, snarky, useless comment. If you don't like the question or I guess the topic, just skip it.

You're more likely to find up-to-date and useful resources on the 'net then in a dead-tree form.

Moreover, you aren't likely to be able to write any meaningful code without cruft, because you'll have to use existing libraries, where that cruft lives.

Giving you a reference to writing C properly--something most folks still don't do--is actually somewhat helpful as opposed to pure snark.

Does C++ have a fixed ABI yet? Is there a fixed name-mangling scheme across compilers? How do I bind other languages to the lambdas?

Re: Duetto: a C++ compiler for the Web going beyond Emscripten and Node.js

#56

Post by flohofwoe » Thu, Oct 31, 2013, 5:11 PM UTC

tomkludy wrote: post #52

flohofwoe wrote: post #43

Earlier quoted context omitted.

Have you ever had to maintain a code base with more then a few hundred thousand lines of code across Flash, Javascript, iOS, Android, PC, OSX, Xbox, PS, Wii, Vita, NintendoDS, ...and whatever other gaming platform is popular at the moment? The "popular platform of the day" changes a lot faster then being able to write new code for it. You need to support that new platform within 3 months or less. Good luck rewriting…

Frankly, I've had to maintain a huge C++-only codebase, and that's why I hope to never write another app in C++. Yours is an argument for a high-level, typesafe, compiled-to-native and compiled-to-javascript language. But IMO the argument falls down when applied to C++, because it is not high-level, it is only marginally typesafe, and it doesn't compile to javascript well at all (tradeoff of either massive performanc…

Yes I see your point to a degree, in a way we're working in a sort of "highlevel C++" most of the time at some performance cost: We have strict coding conventions in place which forbid low-level C/C++ stuff in high-level code (no raw pointers, no C-style arrays, no pointer arithmetics, no C library functions, etc...). Plus static code analysis and tons of runtime asserts. I can't remember the last time we had a buffer overflow or pointer-gone-wild. The performance hit of C++ compiled to JS is surprisingly small (1.5x native performance in Firefox, a bit slower in Chrome, but the gap is getting smaller, this is in the same ballpark as strongly typed bytecode languages like C# or Java).

Re: Duetto: a C++ compiler for the Web going beyond Emscripten and Node.js

#57

Post by dman » Thu, Oct 31, 2013, 5:21 PM UTC

protomyth wrote: post #31

vinkelhake wrote: post #25

Earlier quoted context omitted.

Pray tell us, where does C++ need to be? All C++ programmers who I have talked to welcome most things in C++11. It simplifies their C++-code in many ways. As an example: specifying how to capture variables was something they were already dealing with when writing functors manually, now they have a shorthand syntax for it. As for the reason why non-C++ programmers don't like C++, perhaps you are in a better position t…

Is there a book that teaches best practice C++11 without teaching any of the old cruft?

http://www.artima.com/shop/overview_of_the_new_cpp

Re: Duetto: a C++ compiler for the Web going beyond Emscripten and Node.js

#58

Post by apignotti » Thu, Oct 31, 2013, 5:30 PM UTC

flohofwoe wrote: post #35

apignotti wrote: post #21

Earlier quoted context omitted.

We have written a detailed post a few months ago comparing duetto to emscripten. We also explain why we think it's not a good idea to use a pre-allocated typed array heap: http://leaningtech.com/duetto/blog/2013/05/28/Comparing-to-a...

Disclaimer: speaking strictly from a game-devs perspective: I remember that post and from a game dev's perspective the pre-allocated-memory vs. reclaimed-through-garbage-collection argument is a bit weak IMHO. Games have predictable memory usage, and game devs are used to see memory as a static, finite resource anyway (since that's how it is on consoles). Grabbing a chunk of memory upfront is quite common for games.…

I see your point. Still, I believe the browser environment is different from a console since it is not supposed to monopolize system resources while being used. Managing memory in smaller short lived chunks is more fair for the system as a whole.

Re: Duetto: a C++ compiler for the Web going beyond Emscripten and Node.js

#59

Post by protomyth » Thu, Oct 31, 2013, 5:34 PM UTC

angersock wrote: post #55

protomyth wrote: post #47

Earlier quoted context omitted.

What an amazingly unhelpful, snarky, useless comment. If you don't like the question or I guess the topic, just skip it.

You're more likely to find up-to-date and useful resources on the 'net then in a dead-tree form. Moreover, you aren't likely to be able to write any meaningful code without cruft, because you'll have to use existing libraries, where that cruft lives. Giving you a reference to writing C properly--something most folks still don't do--is actually somewhat helpful as opposed to pure snark. Does C++ have a fixed ABI yet?…

No, its just pure snark. C and C++ are long different. I love K&R[1] C, but is really doesn't show properly written C unless some update occurs that addresses the newer standards and all the fun memory issues.

> Does C++ have a fixed ABI yet? Is there a fixed name-mangling scheme across compilers? How do I bind other languages to the lambdas?

Pretty useless for the purpose of my question. I was asking a simple question, your just in it to spread snark.

1) The original edition was one of my favorite books and what I used to learn C back in the day.

Re: Duetto: a C++ compiler for the Web going beyond Emscripten and Node.js

#60

Post by flohofwoe » Thu, Oct 31, 2013, 6:29 PM UTC

apignotti wrote: post #58

flohofwoe wrote: post #35

Earlier quoted context omitted.

Disclaimer: speaking strictly from a game-devs perspective: I remember that post and from a game dev's perspective the pre-allocated-memory vs. reclaimed-through-garbage-collection argument is a bit weak IMHO. Games have predictable memory usage, and game devs are used to see memory as a static, finite resource anyway (since that's how it is on consoles). Grabbing a chunk of memory upfront is quite common for games.…

I see your point. Still, I believe the browser environment is different from a console since it is not supposed to monopolize system resources while being used. Managing memory in smaller short lived chunks is more fair for the system as a whole.

Well, it's just about how much max memory you need at a time, no matter whether that size is split into many small chunks or allocated as a single block. True, an application which needs very little memory most of the time, and spikes to huge sizes from time to time is not optimal with emscripten's approach.

But I don't want to nitpick all day. The more options we have the better, keep up the good work :)