tag:blogger.com,1999:blog-2681864008001569004.post1972075915309307157..comments2023-12-12T01:10:23.246-08:00Comments on azakai's blog: C++ to JavaScript: Emscripten, Mandreel, and now Duettoazakaihttp://www.blogger.com/profile/00792138494525424175noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-2681864008001569004.post-20785535107418012722013-11-15T10:18:21.624-08:002013-11-15T10:18:21.624-08:00Interesting, thanks for the response! Retweeted ;)...Interesting, thanks for the response! Retweeted ;)<br /><br />Some comments:<br /><br />* Of course the typed array model has allocation overhead in the form of malloc. But usually the C/C++ model of stack+malloc wins over the best GC. It would depend on the use case, of course, and as you say, reusing objects is a good thing to do, and it helps both models.<br /><br />* Interesting that you plan to support the flat memory model for individual types. I wonder though if this won't be complex. Perhaps more importantly, I predict that when you give people that option, they will see that things get faster as they move more types to the flat model, and eventually they will just use that one. (I also predict they'll see lower memory usage in most cases, but as I said in the blogpost, that one could go either way.)<br /><br />* There is object overhead in the JS object model not just for allocated objects, but also for things like pointers, which must be represented as a combination of a JS object reference + a numeric offset (as opposed to just a numeric offset in the flat model), so you must allocate storage for both, typically by allocating a JS object, as I see you do and as llvm-js-backend used to do. Those allocations worry me more than actual C++ object allocations (of course many of them can be removed through optimization, but it would be hard).<br />azakaihttps://www.blogger.com/profile/00792138494525424175noreply@blogger.comtag:blogger.com,1999:blog-2681864008001569004.post-25526123278266577922013-11-15T10:08:32.101-08:002013-11-15T10:08:32.101-08:00Makes sense, yeah. But I think that an important u...Makes sense, yeah. But I think that an important use case is of precompiled libraries, like box2d.js. In that case you have a fixed C++ codebase compiled to JS, and arbitrary handwritten JS later uses it, so they aren't compiled together. I guess I care more about that case personally so it's what I was thinking about as I wrote that.<br />azakaihttps://www.blogger.com/profile/00792138494525424175noreply@blogger.comtag:blogger.com,1999:blog-2681864008001569004.post-5411250139632252442013-11-15T09:40:30.551-08:002013-11-15T09:40:30.551-08:00As promised, a more in-depth follow-up: http://all...As promised, a more in-depth follow-up: http://allievi.sssup.it/techblog/archives/856Alessandrohttps://www.blogger.com/profile/15132040941677782569noreply@blogger.comtag:blogger.com,1999:blog-2681864008001569004.post-7851320191176061082013-11-14T22:36:01.986-08:002013-11-14T22:36:01.986-08:00Great read!
About accessing objects from normal J...Great read!<br /><br />About accessing objects from normal JS code and minification: It should be possible to access them as long as you minify the generated JS and the normal JS at the same time.Danhttps://www.blogger.com/profile/10170807889054711245noreply@blogger.comtag:blogger.com,1999:blog-2681864008001569004.post-2829752451222253782013-11-14T17:09:47.883-08:002013-11-14T17:09:47.883-08:00First of all thanks a lot for this informed and fa...First of all thanks a lot for this informed and fair comparison. As you said a memory model based on typed arrays suffers a lot from memory fragmentation on long running code bases. We believe that using the native memory model of the JS engine (i.e objects) is more fair to other application, both native and on the web, and to the system as a whole. The JS engine will be able to reclaim and compact memory when needed, while a large typed array can, at best, be paged out to swap. By the way we plan in the future to support optional emscripten-like memory style (at the user demand on a on type-by-type basis). That would both increase duetto flexibility and adaptivity to various workloads, and also promote interoperation between code compiled in duetto and in emscripten.<br /><br />Moreover, a quick note on Web API access as offered by duetto: those API are the lowest level access you can have on the platform, but on top of them you can still implement traditional APIs like GLES or SDL. We are currently working on a WebGL based GLES implementation (written in C++, of course) and we will release it ASAP. We are also currently writing an extended blog post with a few more details and we'll let you know when it's out. - Alessandro of the duetto teamAlessandrohttps://www.blogger.com/profile/15132040941677782569noreply@blogger.comtag:blogger.com,1999:blog-2681864008001569004.post-2761933650455807422013-11-14T12:43:42.052-08:002013-11-14T12:43:42.052-08:00Good point, yeah, this is an advantage for Duetto ...Good point, yeah, this is an advantage for Duetto for programs using >2GB of memory (since JS engines limit typed arrays to that).azakaihttps://www.blogger.com/profile/00792138494525424175noreply@blogger.comtag:blogger.com,1999:blog-2681864008001569004.post-34938351832752119062013-11-14T12:38:07.522-08:002013-11-14T12:38:07.522-08:00What about addressable memory? It seems like the t...What about addressable memory? It seems like the typed array approach would limit the available memory due to the 31-bit integer length requirement. On 64-bit machine, it seems like Duetto could take advantage of vastly larger amounts of memory, even if it uses more memory for each individual object.<br />Evan Wallacehttps://www.blogger.com/profile/14490758628494999457noreply@blogger.com