Duetto: A faster and smarter alternative to Emscripten. And more.

We have seen a lot of hype on the Web recently after the announce­ment of Asm.js by Mozilla: a new “extra­or­di­nar­ily opti­miz­able, low-level sub­set of JavaScript”. The sys­tem builds on the work that has been done on Emscripten: a LLVM-based solu­tion which com­piles C++ to JavaScript, allow­ing for an easy port of appli­ca­tions and games to the Web. The excite­ment for Asm.js stems from the fact that, by using a spe­cial vir­tual machine inte­grated in Fire­fox, it can improve the per­for­mance of emscripten-generated code and get it even closer to native performance.

We (Lean­ing Tech­nolo­gies Ltd) would like to intro­duce Duetto, our own LLVM-based solu­tion for pro­gram­ming the Web using C++. And by the Web, we mean both the client and server side of it, but let’s talk about the client side first.

Emscripten han­dles C++ code by emu­lat­ing a full byte-addressable address space. This is def­i­nitely a good solu­tion, but sub­op­ti­mal. Javascript is not based on a byte-addressable address model, but on an object-addressable model: all the acces­si­ble mem­ory is con­tained in some object. But when you think about it, C++ is not that different.

Our solu­tion inte­grates with clang and the LLVM tool­chain and is able to map C++ object-oriented con­structs to native JavaScript objects. It turns out that access­ing objects on mod­ern JavaScript engines is faster than access­ing arrays. By using this (and a few more) tricks we man­aged to get the fol­low­ing, pre­lim­i­nary, results on micro benchmarks.

For each benchmark the best time in 10 runs has been selected. The V8 and Spidermonky JavaScript shells has been used. The respective commits are b13921fa78ce7d7a94ce74f6198db79e075a2e03 and b9d56a1e0a61. *The fasta benchmark has been modified by removing a memory allocation inside the main loop.

For each bench­mark the best time in 10 runs has been selected. The V8 and Spi­der­monky JavaScript shells has been used. The respec­tive com­mits are b13921fa78ce7d7a94ce74f6198db79e075a2e03 and b9d56a1e0a61. *The fasta bench­mark has been mod­i­fied by remov­ing a memory

 

We man­aged to do this by real­iz­ing that by dis­al­low­ing some unsafe C++ capa­bil­i­ties (such as type unsafe pointer cast­ing and pointer arith­metics inside struc­tures) it’s actu­ally pos­si­ble to cre­ate more effi­cient, smaller and faster JavaScript code from C++. Inter­est­ingly enough, we dis­cov­ered that, in most cases, the needed lim­i­ta­tions on the lan­guage are actu­ally spec­i­fied as unde­fined behav­iour!

So, yes, Duetto does need some min­i­mal port­ing to bring C++ code to the Web while emscripten makes it mostly free. What you get in exchange for that is faster per­for­mance with no need of a spe­cial VM and deep inte­gra­tion with the browser. Duetto cre­ates a really seam­less C++ pro­gram­ming expe­ri­ence for the Web:

  • Seam­less inte­gra­tion with the browser envi­ron­ment, com­plete access to the DOM and HTML5 tech­nolo­gies includ­ing WebGL. You can even access and use your favourite JavaScript library or exist­ing JavaScript from C++ by declar­ing the avail­able inter­faces in the C++ code using a sim­ple convention.
  • Seam­less client/server pro­gram­ming, using trans­par­ent RPCs in sin­gle code­base. The com­piler will split the code auto­mat­i­cally in the client part (com­piled to JavaScript) and server part (com­piled to native code).

The Duetto back­end is already in a very advanced state, and we believe it’s already suit­able to bring the first appli­ca­tions to the Web. Espe­cially games, which are our pri­mary tar­get. Unfor­tu­nately our front end is not yet as pol­ished as we would like, as we want to improve the error report­ing to make the port­ing expe­ri­ence as smooth as possible.

We are not yet ready to release Duetto, but we are eager to start open­ing col­lab­o­ra­tions, so if you are inter­ested in bring­ing your C++ appli­ca­tion or game to the web, feel free to con­tact me (alessandro@leaningtech.com). We believe that in six months or less from now we will be able to release a robust prod­uct, most prob­a­bly capa­ble of gen­er­at­ing even faster code. And we want to release it as open source.

For more infor­ma­tion please visit our site: http://www.leaningtech.com

11 Comments

A tale of hidden symbols, weakness and gold

A few days ago I was pro­fil­ing the startup time of the clang com­piler. The call­grind report high­lighted that a rel­a­tively high amount of time was being spent in the _dl_lookop_symbol_x. A quick gdb inspec­tion of the call stack quickly pointed out that the dynamic linker was spend­ing the time doing dynamic relo­ca­tions. Tons of them.

Using objdump -R clang I found out that a whop­ping 42% of them actu­ally con­tained the word “clang” in the man­gled sym­bol names. Deman­gling the names made it clear that they were mostly def­i­n­i­tions of the C++ vir­tual tables for clang inter­nal classes.

Basi­cally 42% of the relo­ca­tions hap­pen­ing at run time were actu­ally look­ing for sym­bols which are obvi­ously defined inside the clang exe­cutable itself. So what’s hap­pen­ing here?

Turns out the prob­lem is a poor inter­ac­tion between the tra­di­tional linker (ld, from the binu­tils pack­age) and C++‘s ODR rule.

ODR stands for One Def­i­n­i­tion Rule and says that any entity in C++ code must be defined only once. This is obvi­ously triv­ial for meth­ods, since if they are defined twice, even in dif­fer­ent trans­la­tion units, there will be an error at link time. There are, though, a few things that are implic­ity defined by the com­piler, for exam­ple the vir­tual tables, which are defined when­ever a class using vir­tual meth­ods is declared. (Here I’m speak­ing infor­mally, I sus­pect the ter­mi­nol­ogy is not 100% cor­rect) Since the vtable is poten­tially defined in more than a trans­la­tion unit, the sym­bols for the vtable are flagged as weak. Weak sym­bols will not con­flict with each other and they will be all dis­carded but one (any one is fine). The sur­viv­ing one will be used by the end prod­uct of the linker.

Unfor­tu­nately, the com­piler does not know if the com­piled object file will be used as part of a dynamic library or as part of a main exe­cutable. This means that it has to treat the vtable sym­bols like any library method, since (if the tar­get is a dynamic library) poten­tially such sym­bols may be over­rid­den by another def­i­n­i­tion in a library or in the main exe­cutable. This has to hap­pen since the ODR rule must also apply across the library bor­ders for proper sup­port of a few things, espe­cially excep­tion handling.

So at com­pile time there is no way around using dynamic relo­ca­tion on the vtable sym­bols. A pos­si­ble workaroud would be to com­pile all the code with the -fvisibility=hidden flag. Unfor­tu­nately this is actu­ally wrong since it may break the ODR rule!

At link time the linker has the chance of elim­i­nat­ing the dynamic relo­ca­tion, since it does know if the tar­get is a main exe­cutable and sym­bols defined in an exe­cutable can­not be over­rid­den by any­thing (not even by LD_PRELOADed libraries). Unfor­tu­nately the tra­di­tional ld linker does not apply this optimization.

The new gold linker, orig­i­nally devel­oped at Google, does tough! It is able to com­pletely erad­i­cate the dynamic relo­ca­tions to inter­nally defined sym­bols, effec­tively reduc­ing the load time.

Moral of the tale: use the gold linker. It should work in most cases (I think ker­nel code is a notable excep­tion) and gen­er­ate faster exe­cuta­bles while con­sum­ing less mem­ory and cpu time dur­ing linking.

And please, dear debian/ubuntu main­tain­ers, link clang using gold.

1 Comment

Linux support for Asus Xonar U1 USB audio device

I got as a Christ­mas gift an exter­nal USB audio device: an Asus Xonar U1. It’s a nice device with a decent audio qual­ity. The audio itself, both in and out works per­fectly with the stan­dard snd-usb-audio ker­nel mod­ule. Unfor­tu­nately the audio con­trols on the device are not stan­dard, so I devel­oped a sim­ple dae­mon and accom­pa­ny­ing udev and pm-utils script to get the device to work. I’ve pub­lished every­thing under the GPL hop­ing that they might be use­ful for some­one else. Feel free to clone and fork my repos­i­tory on github

https://github.com/alexp-sssup/asus-xonar-u1-utils

Flattr this

3 Comments

Lightspark 0.7.0 released

Lightspark 0.7.0 has been released, includ­ing sev­eral months of improve­ments and bug fixes.

Ver­sion 0.7.0:

* Sup­port LZMA com­pressed SWFs [Requires liblzma]
* Improved Bitmap­Data sup­port
* Improved Action­Script com­pat­i­bil­ity
* Improved vir­tual machine per­for­mance and mem­ory con­sump­tion
* Improved XML sup­port
* Exper­i­men­tal sup­port for byte­code opti­miza­tion at run­time
* Improved Exter­nal­In­ter­face (browser inte­gra­tion) sup­port
* Improved per­for­mance of JPEG load­ing
* Sup­port for XML­Socket
* Com­pletely redesigned and improved mask­ing support

You can grab a copy of the sources from launch­pad as usual.

I would also like to ask for infor­ma­tion on a spe­cific prob­lem the project is fac­ing. We are encoun­ter­ing more sites that tries to load library code in the form of SWZ files, which seems to be undoc­u­mented (prob­a­bly obfuscated/encrypted) flash files. Any infor­ma­tion on how to parse/load them is appreciated.

18 Comments

Lightspark 0.6.0.1 released

I’m very happy to annouce a new major release for Lightspark, the open source flash player imple­men­ta­tion. This release includes quite a lot of fixes, both inter­nal and vis­i­ble to users. The most impor­tant ones from a user point of view are prob­a­bly the improved sup­port for PulseAu­dio flat vol­umes, which makes it impos­si­ble for lightspark to manip­u­late the sys­tem vol­ume and the newly added sup­port for the BBC video player. To use BBC site you might need to use AdBlock, which is gen­er­ally rec­om­mended since more often than not flash adver­tise­ments are not sup­ported by Lightspark and causes fail­ures in oth­er­wise sup­ported sites.

From the ChangeLog:
* Enable RTMP sup­port by default, requires librtmp
* Fixed sup­port for IEvent­Dis­patcher imple­men­ta­tion pat­tern
* Improved seri­al­iza­tion robust­ness
* Improved matrix han­dling
* Imple­ment string and name­space pool­ing to reduce mem­ory con­sump­tion
* Proper sup­port for pri­vate name­spaces
* Improved sup­port for fonts
* Sup­port LLVM 3.1
* Fix full vol­ume issue when PulseAu­dio flat vol­umes are enabled
* Ini­tial sup­port for AIR desk­top appli­ca­tions
* Sup­port for www.bbc.co.uk video player

Source tar­ball is, as usual avail­able from Launch­pad.


Flattr this

5 Comments

Lightspark 100% volume issue is now fixed

For some time I’ve received a few reports about lightspark rais­ing the sys­tem vol­ume to 100% (and “killing ears”) when­ever a YouTube clip was started. It took some time for me to fig­ure out what was going on, since I was not able to repro­duce the issue on my sys­tem and of course the code was not will­ingly touch­ing the sys­tem volume.

It turns out that the issue was caused by the recently intro­duced “flat-volume” sup­port in PulseAu­dio. When flat vol­ume is enabled the vol­ume of a stream is absolute and not rel­a­tive to the sys­tem vol­ume. Since the default vol­ume in flash is 100% by spec then Lightspark was unwill­ingly set­ting the sys­tem vol­ume to an extremely high value, and I’m really sorry for that.

I’ve just com­mit­ted a fix in git mas­ter that should fix this prob­lem for good by prop­erly vir­tu­al­iz­ing the vol­ume seen by flash and scal­ing it by the sys­tem vol­ume. I hope this helps peo­ple with flat vol­ume enabled.


Flattr this

,

4 Comments

Lightspark 0.5.7 released

A new ver­sion of Lightspark has been released yes­ter­day. You can give it a try by get­ting the source code from launch­pad. Ubuntu pack­ages should be avail­able shortly from our PPA

Beside a lot of small improve­ments this new release improves the graph­ics capa­bil­i­ties, with a focus on Flash fea­tures used by games.

Here is the changelog:

* Fixed a few mem­ory leaks
* Improved sup­port for BitmapData::draw
* Sup­port for BitmapData::copyPixels
* Sup­port for soft mask­ing
* Sup­port for mem­ory usage pro­fil­ing (mas­sif compatible)

More­over, there has been some work on imple­ment­ing fully accel­er­ated Stage3D sup­port, it’s still in early design phase... but stay tuned.


Flattr this

,

10 Comments

Lightspark 0.5.6 released

After a few months of great pro­gresses under the stew­ard­ship of Jani Mono­ses Lightspark, the mod­ern and open source flash player imple­men­ta­tion is now again being main­tained by me. And I’m very proud to announce the release of lightspark 0.5.6, that brings quite a few new fea­tures and a usual load of sta­bil­ity fixes. Source code is avail­able of course from Launch­pad. Pack­ages should be shortly avail­able for var­i­ous dis­tros. I will also try to get an updated Win­dows build in the next few days.

Here are the new fea­tures, from both 0.5.5 and 0.5.6, since I was too lazy to pub­lish the pre­vi­ous release. My bad, it will not hap­pen again.

  • Fix YouTube sup­port for sev­eral videos
  • Sup­port for cus­tom serialization/deserialization
  • Sup­port RPC (NetConnection::call)
  • Sup­port for PNG images
  • Exper­i­men­tal sup­port for Google Street View
  • Sup­port for Fire­fox 10

As you can see exper­i­men­tal sup­port for Google Street View is now avail­able (kudos to Antti Ajanki for this). More­over, the RPC and seri­al­iza­tion sup­port has been writ­ten in an ongo­ing effort by me to sup­port Far­mVille and sim­i­lar highly inter­ac­tive and com­plex flash games. We are def­i­nitely expand­ing the scope of what is con­sid­ered sup­ported, but there are still some unfin­ished cor­ners in YouTube sup­port, and many other video play­ers do not work yet.

This is way I would like to encour­age young hack­ers, espe­cially stu­dents, that are inter­ested in con­tribut­ing to a com­plex project like lightspark to choose their favorite site using flash to show videos and drop by the #lightspark IRC chan­nel on Freen­ode. Me and the other lightspark devel­op­ers will pro­vide the guid­ance you may need in the first steps. Most often it just a mat­ter of imple­ment­ing or improv­ing a few Flash APIs to see a player start work­ing. And you favorite site (and your name) may be posted here in the next Lightspark release!


Flattr this

4 Comments

Gnome shell extension: GTG in the calendar panel

Hello Gnome Shell lovers,
from today, you can keep an eye on your tasks with style.
Here's the pic:
Here you can install it, here you can get the source code and report bugs.
It works  only with GTG 0.3 and above, that will be released in March. You can also use Trunk, which is quite stable (all you have to do is bzr branch lp:gtg && cd gtg && ./gtg).

One final thing: this is the first time I develop a gnome-shell extension, and I have to say I was impressed by how nice and easy is to code. Kudos Shell people!

Happy holidays!

No Comments

Lightspark 0.5.0 — Bacchus released

After the last round of bug fix­ing and improve­ments over the release can­di­date I’m happy to announce that ver­sion 0.5.0 of Lightspark, a FOSS flash player imple­men­ta­tion aimed at sup­port­ing newer flash files (SWF 9+), is finally released.

Beside sta­bil­ity improve­ments there is no new great new fea­ture since the last released can­di­date (see here for more info). You can grab your copy of the sources on Launch­pad as usual. Pack­ages for both Ubuntu natty and oneiric are avail­able from our PPA. Pack­ages for your favorite dis­tro will be prob­a­bly avail­able in a short time. I’d also like to say “thank you” to all down­stream pack­agers for the crit­i­cal work they have always done.

As always bug report­ing and test­ing is very appre­ci­ated. If you need any help you can drop into the #lightspark chan­nel on Freen­ode.

Flattr this

,

8 Comments