Archive for November, 2013

Comparing Duetto with Emscripten: a follow-up

logo_duetto_quadrato_192

Yes­ter­day, Alon Zakai (alias krip­ken, cre­ator of Emscripten) wrote an excel­lent post com­par­ing three C++ to JS com­pil­ers: Man­dreel, Emscripten and Duetto. We would like to pro­vide a few more details regard­ing Duetto as we feel that, although the com­par­i­son was def­i­nitely fair, we can add some points which have been missed.

Mem­ory model: Con­trar­ily to Man­dreel and Emscripten, which emu­late a tra­di­tional flat address space using a sin­gle­ton typed array, Duetto maps C++ objects to JS objects. This nat­u­rally implies an over­head both in terms of meta-data that the JS engine man­ages and in terms of com­pu­ta­tional work that the Garbage Col­lec­tor (GC) needs to do. While these may look like major dis­ad­van­tages, other fac­tors should be taken into account. The com­pu­ta­tional over­head does not go wasted, as it is func­tional to keep mem­ory usage in check and make sure that the amount of occu­pied mem­ory is closer to the amount actu­ally required.

In addi­tion, the typed array based mem­ory model incurs in some over­head as well,  as mem­ory areas are still man­aged using some kind of mal­loc. And they also suf­fer a lot from frag­men­ta­tion as the browser can’t reclaim mem­ory in the mid­dle of the array which is not cur­rently being used.

We strongly believe that the duetto mem­ory model being based on JS objects is more fair to other appli­ca­tions, both native and web-based and to the user’s sys­tem as a whole. If the sys­tem gets tight on mem­ory, it is pos­si­ble for the browser to reclaim cur­rently unused objects used in code gen­er­ated by duetto, on the other hand when a large typed array is used, the sys­tem can at best page-out unused or sel­dom used pages to swap since it has no way to know what mem­ory is actu­ally used and what is not. On the other hand it is def­i­nitely true that fre­quently allo­cat­ing and deal­lo­cat­ing objects may cause an unac­cept­able slow­down, but this is actu­ally true for native pro­grams as well and the solu­tion is to re-use the same objects over and over (for exam­ple by cre­at­ing pools) at the appli­ca­tion level, and this is some­thing that is, of course, pos­si­ble using duetto as well. Gen­er­ally we believe that using JS objects also make duetto com­piled code more sim­i­lar to hand­writ­ten JS code, which is already han­dled very well by JS engines, with the added advan­tage of guar­an­teed type immutabil­ity which can be exploited by the engine to gen­er­ate faster code. Still, duetto is flex­i­ble enough that it will be pos­si­ble, in the future, to sup­port using an emscripten like mem­ory model on a type-by-type basis. This would be use­ful to adapt to var­i­ous work­loads and for com­pat­i­bil­ity with code com­piled by emscripten.

APIs: Duetto is built around the con­cept that the browser is a plat­form hav­ing JS as the machine lan­guage. Such plat­form has APIs like WebGL, HTML5 Can­vas, DOM events and so on which are the low­est level acces­si­ble func­tion­al­i­ties. With Duetto you can use all of them directly from C++ and no JS wrap­per code is required.

What about the cross plat­form APIs used on native sys­tems like SDL and Ope­nAL? Well, we don’t cur­rently sup­port them, but they can be ported to Duetto by writ­ing a new back­end for the browser plat­form, sim­i­larly to what has been already done to port them to Win­dows, Linux and Mac. And using duetto it is pos­si­ble to write such port­ing code directly in C++ because you have direct access to the browser APIs. Once the cross plat­form APIs sup­port duetto, appli­ca­tions using them will run as well with­out much (or any) work.

And what about GLES? Well, we received so many requests for this func­tion­al­ity that we are work­ing on pro­vid­ing a WebGL based GLES imple­men­ta­tion our­selves. We plan to release it very soon. With that it should be pos­si­ble to build pro­grams using GLES with duetto by only chang­ing the win­dow­ing sys­tem ini­tial­iza­tion code, sim­i­larly to port­ing from win­dows’ WGL to X11 glX.

C++ com­pat­i­bil­ity: Alon cor­rectly states that duetto has “par­tial” C++ com­pat­i­bil­ity. This is true, but given the incred­i­ble amount of capa­bil­i­ties that the C++ lan­guage has, it is impor­tant to clar­ify what these lim­i­ta­tions are.

Let’s start from the basis: our C++ com­piler was of course not writ­ten from scratch, but was based on clang. This means that we inherit com­plete sup­port for all C++ fea­tures, includ­ing recent and advanced ones like C++11, tem­plate sup­port and lambda. And we actu­ally use such fea­tures in the C++ code which man­ages trans­par­ent client/server RPCs.

The lim­i­ta­tions are more about a few spe­cific unsup­ported capa­bil­i­ties, cur­rently the major ones are: miss­ing sup­port for vir­tual inheritance/virtual base classes, some issues with pointer com­par­i­son in a cou­ple of cor­ner cases and miss­ing sup­port for some parts of the stan­dard library. But we would like to stress that those lim­i­ta­tions are (mostly) non struc­tural and we will do our best to increase the com­pat­i­bil­ity as much as pos­si­ble while still be coher­ent with C++ phi­los­o­phy of expos­ing all plat­form capa­bil­i­ties and lim­i­ta­tions to the user.

Per­for­mance: We have worked with com­puter sys­tems long enough to all agree that micro-benchmarks have lit­tle to do with per­for­mance on real world sce­nar­ios. We also know that Duetto still pro­duces sub­op­ti­mal code for many com­mon cases that we plan to fix. We look for­ward to try and pro­file Duetto gen­er­ated code from a large, real world code base, to find out how it per­forms and what needs to be optimized.

In sum­mary, we think that Alon’s review of our tech­nol­ogy is pretty accu­rate, and we look for­ward mak­ing more and more of Duetto’s fea­tures known to the com­mu­nity, with ded­i­cated posts and doc­u­men­ta­tion. We have been impressed by the feed­back we got with our first release — and look for­ward to hear your opinion.

Duetto release 0.9.1 is now avail­able as source tar­balls and bina­ries for Ubuntu/Debian (PPA) and Win­dows. MacOSX builds will be avail­able soon. Feel free to report bugs, and request fea­tures here.

Fol­low us on @leaningtech, Face­book and at www.leaningtech.com for updates.

No Comments

Comparing Duetto with Emscripten: a follow-up

logo_duetto_quadrato_192

Yes­ter­day, Alon Zakai (alias krip­ken, cre­ator of Emscripten) wrote an excel­lent post com­par­ing three C++ to JS com­pil­ers: Man­dreel, Emscripten and Duetto. We would like to pro­vide a few more details regard­ing Duetto as we feel that, although the com­par­i­son was def­i­nitely fair, we can add some points which have been missed.

Mem­ory model: Con­trar­ily to Man­dreel and Emscripten, which emu­late a tra­di­tional flat address space using a sin­gle­ton typed array, Duetto maps C++ objects to JS objects. This nat­u­rally implies an over­head both in terms of meta-data that the JS engine man­ages and in terms of com­pu­ta­tional work that the Garbage Col­lec­tor (GC) needs to do. While these may look like major dis­ad­van­tages, other fac­tors should be taken into account. The com­pu­ta­tional over­head does not go wasted, as it is func­tional to keep mem­ory usage in check and make sure that the amount of occu­pied mem­ory is closer to the amount actu­ally required.

In addi­tion, the typed array based mem­ory model incurs in some over­head as well,  as mem­ory areas are still man­aged using some kind of mal­loc. And they also suf­fer a lot from frag­men­ta­tion as the browser can’t reclaim mem­ory in the mid­dle of the array which is not cur­rently being used.

We strongly believe that the duetto mem­ory model being based on JS objects is more fair to other appli­ca­tions, both native and web-based and to the user’s sys­tem as a whole. If the sys­tem gets tight on mem­ory, it is pos­si­ble for the browser to reclaim cur­rently unused objects used in code gen­er­ated by duetto, on the other hand when a large typed array is used, the sys­tem can at best page-out unused or sel­dom used pages to swap since it has no way to know what mem­ory is actu­ally used and what is not. On the other hand it is def­i­nitely true that fre­quently allo­cat­ing and deal­lo­cat­ing objects may cause an unac­cept­able slow­down, but this is actu­ally true for native pro­grams as well and the solu­tion is to re-use the same objects over and over (for exam­ple by cre­at­ing pools) at the appli­ca­tion level, and this is some­thing that is, of course, pos­si­ble using duetto as well. Gen­er­ally we believe that using JS objects also make duetto com­piled code more sim­i­lar to hand­writ­ten JS code, which is already han­dled very well by JS engines, with the added advan­tage of guar­an­teed type immutabil­ity which can be exploited by the engine to gen­er­ate faster code. Still, duetto is flex­i­ble enough that it will be pos­si­ble, in the future, to sup­port using an emscripten like mem­ory model on a type-by-type basis. This would be use­ful to adapt to var­i­ous work­loads and for com­pat­i­bil­ity with code com­piled by emscripten.

APIs: Duetto is built around the con­cept that the browser is a plat­form hav­ing JS as the machine lan­guage. Such plat­form has APIs like WebGL, HTML5 Can­vas, DOM events and so on which are the low­est level acces­si­ble func­tion­al­i­ties. With Duetto you can use all of them directly from C++ and no JS wrap­per code is required.

What about the cross plat­form APIs used on native sys­tems like SDL and Ope­nAL? Well, we don’t cur­rently sup­port them, but they can be ported to Duetto by writ­ing a new back­end for the browser plat­form, sim­i­larly to what has been already done to port them to Win­dows, Linux and Mac. And using duetto it is pos­si­ble to write such port­ing code directly in C++ because you have direct access to the browser APIs. Once the cross plat­form APIs sup­port duetto, appli­ca­tions using them will run as well with­out much (or any) work.

And what about GLES? Well, we received so many requests for this func­tion­al­ity that we are work­ing on pro­vid­ing a WebGL based GLES imple­men­ta­tion our­selves. We plan to release it very soon. With that it should be pos­si­ble to build pro­grams using GLES with duetto by only chang­ing the win­dow­ing sys­tem ini­tial­iza­tion code, sim­i­larly to port­ing from win­dows’ WGL to X11 glX.

C++ com­pat­i­bil­ity: Alon cor­rectly states that duetto has “par­tial” C++ com­pat­i­bil­ity. This is true, but given the incred­i­ble amount of capa­bil­i­ties that the C++ lan­guage has, it is impor­tant to clar­ify what these lim­i­ta­tions are.

Let’s start from the basis: our C++ com­piler was of course not writ­ten from scratch, but was based on clang. This means that we inherit com­plete sup­port for all C++ fea­tures, includ­ing recent and advanced ones like C++11, tem­plate sup­port and lambda. And we actu­ally use such fea­tures in the C++ code which man­ages trans­par­ent client/server RPCs.

The lim­i­ta­tions are more about a few spe­cific unsup­ported capa­bil­i­ties, cur­rently the major ones are: miss­ing sup­port for vir­tual inheritance/virtual base classes, some issues with pointer com­par­i­son in a cou­ple of cor­ner cases and miss­ing sup­port for some parts of the stan­dard library. But we would like to stress that those lim­i­ta­tions are (mostly) non struc­tural and we will do our best to increase the com­pat­i­bil­ity as much as pos­si­ble while still be coher­ent with C++ phi­los­o­phy of expos­ing all plat­form capa­bil­i­ties and lim­i­ta­tions to the user.

Per­for­mance: We have worked with com­puter sys­tems long enough to all agree that micro-benchmarks have lit­tle to do with per­for­mance on real world sce­nar­ios. We also know that Duetto still pro­duces sub­op­ti­mal code for many com­mon cases that we plan to fix. We look for­ward to try and pro­file Duetto gen­er­ated code from a large, real world code base, to find out how it per­forms and what needs to be optimized.

In sum­mary, we think that Alon’s review of our tech­nol­ogy is pretty accu­rate, and we look for­ward mak­ing more and more of Duetto’s fea­tures known to the com­mu­nity, with ded­i­cated posts and doc­u­men­ta­tion. We have been impressed by the feed­back we got with our first release — and look for­ward to hear your opinion.

Duetto release 0.9.1 is now avail­able as source tar­balls and bina­ries for Ubuntu/Debian (PPA) and Win­dows. MacOSX builds will be avail­able soon. Feel free to report bugs, and request fea­tures here.

Fol­low us on @leaningtech, Face­book and at www.leaningtech.com for updates.

No Comments