haXe Blog

Strands™ Summer 2008 haXe Project Announcement

Franco Ponticelli — 2008-04-29 18:36:29

We are pleased to announce that Strands.com, a provider of social recommendation technologies, is hosting a student open source coding summer project, focused solely on haXe.

You can find more information on the project and how to participate on this announcement page: http://labs.strands.com/Summer2008HaxeProject/

This project has very similar funding and terms to the 'other' open source summer coding project that you may be aware of. However, it is designed solely for current students in the haXe community.

Strands.com will provide funding for not more than 3 students, for not more than 2 projects. To see a list of suggested projects, please see the announcement page. We will prioritize the listed projects as well as those that get the most student interest.

Currently, the project involves myself (a PhD candidate at the Indiana University School of Informatics), and Franco Ponticelli, notable haXe community member and co-author of the recent book on haXe. We look forward to making this summer the "Summer of haXe"!

If you have any questions about the project, please use this mailing list.

Best,

- Justin and Franco

Physaxe : haXe Physics Engine

Nicolas Cannasse — 2008-04-06 19:18:04

I'm please to announce the 1.0 Release of Physaxe : a haXe 2D Rigid Body Physics Engine heavily optimized for Flash Player 9.

A demo is always better than words, so you can play the following SWF, use 1-8 keys to change the demo and click to fire a block :

(if you want to check the real CPU spent by physaxe, you can press the 'D' key to disable drawing, which takes most of the CPU)

See the Physaxe project page for more informations.

Enjoy !

Nicolas

Towards haXe 2.0

Nicolas Cannasse — 2008-03-24 10:31:46

After 1.19 Release, I'm planning to roll up several changes in the language and its libraries, with some of them which might require some code changes. This is done in order to "cleanup" features and libraries that were added incrementally during the past 2 years of development and prepare the language for future additional platforms.

All these changes can be discussed on the mailing list and you're welcome to submit your own there as well.

The list of changes are available on the haXe Wiki.

Flash 9 Optimizations

Nicolas Cannasse — 2008-03-08 15:51:45

The new virtual machine than can run AS3 and haXe languages in the Flash Player 9 brings a lot of additional speed for many common operations. This is very good news for developers since you can now write more complex algorithms in Flash such as 3D or Physics engine with correct performances.

However, there are still several pitfalls since some operations are pretty slow when compared to others :

creating a new object is slow : if you have a lot of short living objects that are allocated frequently, it's better to create a "Allocator" class that will store a list of reusable instances.
calling a lot of methods is not so fast : when you have some small methods that are very often called, it's often faster to rewrite the code directly in the calling method. For example, given a Point class :
```
var p = new Point(4,5);
// the expression :
p.add(p2.x,p2.y);
// would be faster if written directly :
p.x += p2.x;
p.y += p2.y;
```
This process of replacing a method call with the actual code is called inlining, and haXe compiler has support for an inline keyword so that you can define which methods will be automatically inlined by the compiler when called (see haXe Documentation)
accessing static vars and functions is slow : you can either create an instance and use instance variables and methods instead of static ones or use the haXe inline keyword.

reading and writing into arrays is slow : this is very bad news. The only native data structure of Flash9 is painfully slow. It's a lot faster to access a typed instance field than to access an array. One way to optimize that is to create your own linked list :

// a cell containing instances of MyClass
class MyCell {
    public var elt : MyClass;
    public var next : MyCell;
    public function new( elt, next ) {
        this.elt = elt;
        this.next = next;
    }
}
// a list managing a chained list of MyCell
class MyList {
    public var head : MyCell;
    public function new() {
        head = null;
    }
    // add an element at the beginning of the list 
    public function add( elt : MyClass ) {
        head = new Cell(elt,head);
    }
}
// You can then iterate on your list this way :
var l : MyCell = mylist.head;
while( l != null ) {
    var e : MyClass = l.elt;
    // ... do something with e ...
    l = l.next;
}

First, the good news : using a typed linked list is 2 to 3 times faster than using an Array ! (if you want to test that in AS3, make sure to type all your variables, the code here is entirely typed thanks to haXe type-inference)

Now the bad news : you will have a define a MyList and MyCell class for each different class you want to store. So you have to copy/paste the same code again and again. Using Dynamic (or * in AS3) is out of question here since that would require a cast for each reading of an element that would be slow again.

Current haXe users know that the language have typed arrays in order to ensure type-safety. You can also define your own parametrized classes, so it's pretty easy to write-once the following :

// a cell containing any instance
class Cell<T> {
    public var elt : T;
    public var next : Cell<T>;
    public function new( elt, next ) {
        this.elt = elt;
        this.next = next;
    }
}
// a list managing a chained list of cells
class List<T> {
    public var head : Cell<T>;
    public function new() {
        head = null;
    }
    // add an element at the beginning of the list 
    public function add( elt : T ) {
        head = new Cell(elt,head);
    }
}

The problem is that typed-parameters are only used for compile-time type checking. Since the Flash9 VM does not support them, they disappear in the compiled code and are then replaced by the AS3 * type, so all your accesses to the List will need an additional cast... we're back the problem.

Thinking about the problem, I was thinking then : why not let the compiler generate a specific version of the List class for each parameter it will be used ? This way it would generate a List_User and a Cell_User class that can contains User instances, and so on.... automatically at compile time !

That approach was proved quite easy to implement, so it works now in haXe. In order to let the user choose between speed and codesize, the default haXe List class has not been modified, but instead a new haxe.FastList class has been added (accessible when compiling for Flash9).

In order to create your own "generic" classes that will be specialized when used with a type parameter, you can simply have your class implements the haxe.rtti.Generic interface.

Both haxe.FastList and haxe.rtti.Generic are now on haXe CVS (you can download and compile it to give it a try) and will be part of the 1.19 Release.

Conclusion : there's a lot of painful things to do when you want to optimize your code to run fast on Flash9. But thanks to haXe inline and generics, it's a lot more easy to do while keeping your code clean and maintainable.

Professional haXe and Neko Book

Lee McColl Sylvester — 2008-01-31 13:10:07

The Wrox Professional haXe and Neko book by Lee McColl Sylvester and Franco Ponticelli, is now available for purchase from Amazon.

This book, having taken a year to write, is the combined efforts of Lee and Franco, with much help from Nicolas Cannasse, Daniel Fischer, Ritchie Turner (aka. Blackdog) and the team at Wiley & Sons. The book is a comprehensive overview of the haXe language and Neko virtual machine, sporting 648 pages of infomation. The chapters include:

PART I

Chapter 1: Introducing haXe
Chapter 2: Installing and Using haXe and Neko
Chapter 3: Learning the Basics
Chapter 4: Controlling the Flow of Information
Chapter 5: Delving into Object-Oriented Programming
Chapter 6: Organizing Your Code
Chapter 7: When Things Go Wrong

PART II - Server Side, JavaScript, and Flash, Oh My!

Chapter 8: Cross Platform Tools
Chapter 9: Building Websites in haXe
Chapter 10: Seperating Design Using Templates
Chapter 11: Performing Server-Side Trickery
Chapter 12: Building Interactive Content With Flash
Chapter 13: Replacing the Need for an IDE
Chapter 14: More Interactive Content with JavaScript
Chapter 15: Putting It All Together with haXe Remoting

PART III - Extending The Possibilities

Chapter 16: haXe Advanced Topics
Chapter 17: Desktop Applications with Neko
Chapter 18: Desktop Flash with SWHX
Chapter 19: Multimedia with Neko
Chapter 20: Extending haXe with C/C++
Appendix A: Semantic HTML

Please, if you do buy it, Franco and I would be grateful if you could use our associates links. We don't get much for the sales of the book, and to be honest, that's not why we wrote it, but if we can buy ourselves books from the sale of this one, then we get some reward for our hard work:

You'll have to wait about 10 days longer from the .co.uk link, as it is released ten days later, but that should make the delivery date about the same if you live in the UK.

Again, thanks in advance to those that buy it, and we hope you enjoy the book. As always, stay tuned to the list for haXe and Neko updates.

haXe Talk at 24C3

Nicolas Cannasse — 2008-01-20 18:08:18

Here's the talk I gave about haXe at 24C3. You can download the HD version or view the talk in streaming here :

Enjoy !

haxeVideo 1.0

Nicolas Cannasse — 2007-12-16 02:29:23

At last, haxeVideo 1.0 has now been officially released !

haxeVideo is an opensource video streaming server entirely written in haXe.

You can get it now from http://haxevideo.org !

Features include :

FLV streaming using RTMP protocol
Webcam and Microphone recording to FLV file
Live streaming for web conferencing
light and fast scalable server
only 50 KB of server source code : modify whatever you need !

Big thanks to the Red5 team and Roberto Saccon for helping me when I had trouble with RTMP implementation !

And I hope you'll enjoy the opening test video ;)

Nicolas

[OT] Fanfare

Nicolas Cannasse — 2007-11-21 23:22:23

This blog tends to be a bit too much technical sometimes, so what about a little Fanfare for a change ? One for geeks, of course.

Fast Flash9 Fixed Point Sine

Nicolas Cannasse — 2007-11-11 23:47:23

Recently I've been starting playing a bit with Flash9.

A few months ago, after adapting the haXe compiler to target the AVM2 (which also runs ActionScript3), I wrote the hxASM library which enable you to write Flash9 assembler in haXe.

Yesterday, I started to micro-benchmark some of the most common operations in order to check what kind of thing is expensive and what kind of thing can be done fast.

I was using some Bench program written in haXe, then generating the corresponding AS3 code by using the haXe-to-AS3 Generator, and comparing the results of both outputs.

This way, I could find that some of the operations in haXe were a bit underoptimized, so now everything should be fixed on CVS and these improvements will be included in next 1.17 release.

I was also able to get some interesting conclusions :

array accesses are not that fast
static calls are very slow compared to method calls (like 10 times slower). That's a bit strange given that the VM should be able to resolve them at JIT'time and them optimize better
in particular, while floating point and integer arithmetics operations are very fast, calls to Math functions such as "sin" or "cos" are very slow

As you know, games and 3D engines use a lot of Math functions, so I was interested in writting an optimized Math.sin function. Using precomputed tables would not work because of array access time, so I was thinking to use some approximative float calculus (like Taylor series). After a bit of googling, I found this blog post which was exactly what I was looking for. This can be rewrote as the following code (without precomputed constants) :

function fastsin( x : Float ) {
   // clamp
   if( x < -PI ) x += 2*PI else if( x > PI ) x -= 2*PI;
   // approximate
   var sin = (x - x * abs(x) / PI) * 4 / PI;
   // adds correction
   var fix = sin + .225 * (sin * abs(sin) - sin);
   // we're done !
   return fix;
}

This code does not calculate exactly a sin, but gives a very very good approximate that can be perfectly used in games or 3D.

Clamping

First remark : the clamping of value in the [-PI,PI] range is a bit slow and inacurate in the case the value is 10*PI for example.

So how can we easily clamp a Float value between two bounds ?

Using a modulo does not work very well in that case since we want a mod(2PI). We need then some kind of overflow... just like Flash9 int type which is constraint into the range [-2^31,2^31].

Does that remind you something ? Let's do the maths :

var range = 2^31 / PI;
x = int(x * range) / range;

And here it is ! Superfast accurate clamp !

Fixed point

Another good thing to know is that integer calculus is a lot faster than floating point calculus, so making the rest of the fastsin operations using integer calculus would be a lot faster.

But we have floating point values, so how do we turn them into integer operations ? By using Fixed Point integers. For those that don't know about it, here how it works :

you convert a float to an int by multiplying it by K=2^15/PI, so you have a 0,000096 precision which should be enough for our fastsin.
Since our float is between -PI and PI, it will turn into an integer between [-2^15,2^15] which is good since it means we can multiply two of these integers without any overflow.
addition and substraction works the same, since (a*K)+(b*K) == (a+b)*K
for multiplication however, you have (a*K)*(b*K) = (a * b) * K * K so once multiplied you have to divise by K which is not very easy here, but there will be some trick.
once calculus is terminated, you can simply divide your integer by K to get the float result

Let's get things into practice. First, after clamping, we reduce the integer from [-2^31,2^31] to [-2^15,2^15] range :

var x = int(angle * 2^31 / PI) >> 16;
// with constant
var x = int(angle * 683565275.57643158978229477811035) >> 16;

Then we can perform several simplifications of the sin variable calculus :

// replace x by x/K
var sin = (x/K - x/K * abs(x/K) / PI) * (4 / PI);
// expand
var sin = (x - x * abs(x) / (PI * K)) * (4 / PI) / K;
// replacing K
var sin = (x - x * abs(x) / (PI * 2^15 / PI)) * (4 / PI) / K;
// reducing and multiplying by 2^30/PI
var sinB = (x - x * abs(x) / 2^15) * (4/PI) * (2^30/PI) / (2^15/PI);
// optimizing
var sinB = (x - ((x * abs(x)) >> 15)) * 41721;

Here, we then have calculated sinB = sin*2^30/PI using only integer calculus. Now that the first part is optimized, we can also continue with the second part :

// replace sin by sinB/(2^30/PI)
var fix = sinB/(2^30/PI) + .225 * 
            (sinB/(2^30/PI) * abs(sinB/(2^30/PI)) - sinB/(2^30/PI));
// expand
var fix = (.775*sinB + .225*sinB*abs(sinB) / (2^30/PI)) / (2^30/PI);
// factorize
var fix = (sinB + (.225/.775)*PI*sinB*abs(sinB)/2^30) * .775*PI/2^30
// factorize, calculate
var fix = (sinB + ~0.912*(sinB/2^15)*abs(sinB/2^15)) * .775* PI/2^30
// tmp variable
var sinC = sinB >> 15;
var fix = (sinB + ~0.912 * sinC * abs(sinC)) * .775*PI/2^30;
// one last trick for approximating 0.912 multiplication
var fix = (sinB + ((sinC * abs(sinC)) >> 9) * 467) * .775*PI/2^30;
// now calculate the last division real value
var fix = (sinB + ((sinC * abs(sinC)) >> 9) * 467)
return fix / 441009855.21060102566599663103894;

Let's explain a bit the 0.912 trick here. In fixed point, we want to do only a multiplication by an integer. So we have to find an good balance between precision and speed. So we start calculating all powers of 2 multiplied by 0.912, until we find that (2^9 * 0.912) ~= 467, so we can then substitute 0.912 by 467/2^9, and use a right shift instead of the division.

Ouch ! We're done ! Let's write everything down : this is the haXe version (you can't compile it with haXe 1.16 since __int__ was just added on CVS) :

function fastsin( x : Float ) {
   // clamp to [-2^15,2^15]
   var x = (untyped __int__(angle*683565275.576431589782294)) >> 16;
   // approximate
   var sinB = (x - ((x * (x<0?-x:x)) >> 15)) * 41721;
   // adds correction
   var sinC = sinB >> 15;
   var fix = sinB + (sinC * (sinC<0?-sinC:sinC) >> 9) * 467;
   // we're done
   return fix / 441009855.21060102566599663103894;
}

Doing some quick tests gives the following :

approximation works as good as the floating point version, with a difference of less than 0.00129 between the real sinus calculus and the fast one.
when called as a method, speed compared to Math.sin is 225% (more than two times faster), when inlined 320% (more than three times faster) !

Bad news and good news !

By doing this optimization, we could manage to remove entirely the cost of the static call. It means that putting fastsin inside a static function would go slower that real Math.sin. But the good news is that we can inline the code.

This is something that haXe will support soon. You will be able to mark fastsin method as inline and each time it's called, it will insert at compiletime in your code the 5 lines of the method body instead of the actual call, giving you the best speedup you can get.

The bad news is for ActionScript3 users. I don't know why, but even with typing everything to int, some of the integer operations are not correctly optimized by the MXMLC compiler. Hence, it actually performs quite bad...

Now, a very good news : if you're interested in getting the best performances from Flash9 VM, you will have to use haXe :)

Nicolas Cannasse

EcmaScript 4 and the Web

Nicolas Cannasse — 2007-11-03 16:50:46

Recently was published a proposal for extending the current Javascript language with a good set of new features : classes, optional type system, and a lot more. This proposal is known as EcmaScript4 (ES4) and was built by the TG1 discussion group composed of representatives from Mozilla, Adobe, Opera, Microsoft, and maybe a few others.

While things were going smoothly up to now, there is currently a quite big debate among some of the TG1 participants and other people from the Javascript (JS) community (see the whole public discussion if you have free time).

Why this may seem a bit technical, it can have a lot of impact of our (web developers) life.

Stakes

At first, and in order to understand the situation we are in, there are different kind of conflicting interests at stake, so let's try to sumup a little bit :

Mozilla is pushing for big changes : they are big users of Javascript : a lot of their applications are scripted with JS, they have XUL, ... More language features would help them in their everyday work. And surely they would be happy if ES4 would become the standard for web development.
Adobe fully supports Mozilla in this push for ES4. For some time now, they are targeting developers with their new products and want people to forget about the whole "proprietary plaform" label that is stick to Flash. Their strategy is then to support a standardized language. They already implemented a reduced ES4 version called ActionScript3 and the Virtual Machine that runs it (Tamarin) has been donated... to Mozilla.
On the other side, this is exactly what Microsoft is fearing : they have been investing a lot of time and money into their own prioprietary technologies, like C# and more recently released Silverlight which is seen as a Flash competitor. They would not like to see a new language that they don't control, that was designed by an alliance of their competitors, and that (horror) doesn't run yet on .NET
there are fears that ES4 would "break the web" since it seems that Mozilla want to replace current Firefox JS Virtual Machine (SpiderMonkey) with a new one that would run ES4. ES4 is is supposed to be backward compatible with JS, but when you change implementation, you might get some bugs and incompatibilities anyway, since even with a lot of testing, software is rarely perfect.
there are others comments for people of the embedding browser market, such as Opera. For obvious reasons, their fears are more about the size of the runtime that would be needed to run ES4, memory consumption etc.
some JS developers prefer small-steps improvements to one big-step one. For several reasons. One is be pure conservatism, the other is that when your daily technology evolves, you feel huge pressure to keep up-to-date with the latest features. And if you read ES4 proposal, you can see that while you can write plain'old JS, the number of new features to learn is huge, and it would take a lot of time for the average JS programmer to master the language.

I hope that I didn't forget anyone opinion, I didn't include technical discussions about the usefulness of ES4 features but with that many differents point of view it seems already quite complicated.

From here, what ?

As we see, each party has more or less its own internal agenda, which is perfectly normal in an human world. But at this point, the situation is pretty blocked.

Mozilla and Adobe seems to want to push ES4 up to the end, and Microsoft will not accept it. I personaly don't care about Microsoft opinion EXCEPT that they are the ones doing Internet Explorer (IE), you know, that (still) 80% market share internet browser, the one your users are visiting your website with...

So, as developers, we're out of luck.

Mozilla and Adobe thought the same and came up with the ScreamingMonkey project, which is an ES4 runtime that can be installed for Internet Explorer. Nice, but how long will that work ? Given that Microsoft has no intention of helping, I can foresee that each IE/Windows update will break something. In short : I'm not sure it's possible in the long term to put a plugin into an application while its owner does not want to hear about it !

So, as developers, we're out of luck....

Another solution ?

Now, I'll take a bit of time to write about my own (not hidden) agenda.

haXe is a highlevel programming language that has been developed for few years now and which has a still small but growing community of users. One of the particularity of haXe is that it can compiles to Javascript. It means that you get all the benefits :

you are using an highlevel language with compile-time static typing
the haXe language let you also do dynamic stuff that is helpful for DOM/AJAX implementations
in the end, you are generating a .js that can be run by all current browsers
it's open source
it can interoperate with existing JS libraries
if you don't like it, simply use Javascript !

<irony>

So my suggestion to Mozilla and Adobe would be to drop ES4 and use haXe instead :) There's already an open source compiler available, and a Book on the language should be published soon... unless of course haXe features are not good enough, but I'm open to suggestions and discussions on this particular topic.

</irony>

And developers ?

More seriously, it's a shame that nobody asks to the main people concerned by such a decision what would they like to have. The main people here being web/JS developers, which as far as I know are not represented in the ES4 commitee.

That's actually one of the big problem I have with ECMA or W3C. Everything is decided by a group of people that represent corporate interests, then they publish a huge document which is often a bloated specification that only big companies with enough cash can afford to implement.

What was useful a few years ago in order to ensure intercompability between different proprietary vendors is no longer needed when there is one single open source implementation.

That does not remove the need for a clear specification that needs to be either respected or modified, but at least that gives additional agility in the process of designing this specification.

As a language designer, I prefer to experiment long time with a feature, then if it was useful for enough people of the community, it's added to the language. If not it's removed. That's the way software should be designed, at least IMHO.

Conclusion

So what would be wise to do now that we're here ? My suggestion would be to forget about languages, forget about syntax or features, forget about corporate wars (if possible).

What are the problems with current Javascript ? As for me they are :

browser apis incompatibilities
security
speed (slow)

So why not have every browser vendor sit around the table and resolve first these issues that are the ones really concerning the developers, instead of losing their time and energy in these fights ? Then, as for improving the language, I think it would be better if it was a commmunity work, since corporations can fight between them but no one has the interest to fight against the developers community.

Nicolas Cannasse