Re: [Vala] benchmarks on Vala?

[Sandino Flores Moreno <tigrux gmail com>]

My grain of salt.

I started, just for fun, a programming language for glib named gel:
https://github.com/tigrux/gel

And the benchmark I made, calculates all the primes between 2 and 50k.
https://github.com/tigrux/gel/blob/master/comparison/primes.gel


[var sieve [array]]

[for n [range 2 50000]
    [if [all [lambda [i] [% n i]] sieve]
        [append sieve n]
    ]
]

[print "Calculated " [len sieve] " primes"]

[quit]



1) In the first stages, it used gobjects, it was taking around 2 minutes.

2) Then, I moved to use only compact classes, the time decreased to 40 seconds.

3) After that, I implemented a mechanism to reuse objects, based on a pool,
to avoid calls to g_new, g_free and g_hash_table_new. It then
decreased to 30 seconds.
(that mechanism is currently out of git, because conflicted other experiments)

4) Finally, instead of using g_value_get_int, g_value_set_double, etc
I used macros
to directly get the fields from the GValue structure. The time
decreased from 30 to 20 seconds.

The same code, in python, takes only 2 seconds.

So, no matter if your code is in C or not, there is always lot of room
for improvements,
specially because GLib/GObject tends to have much code to validate and be safe,
that make it slow but trustful.




2011/1/18 Jan Hudec <bulb ucw cz>:
> On Tue, Jan 18, 2011 at 09:18:06 -0300, Erick Pérez Castellanos wrote:
> > I haven't prove it but theoretically can't be slower since Mono
> > applications are running on the top of a virtual machine and Vala
> > applications are native code executed, so kinda hard to think that
> > Mono is faster than Vala, eh !!!
>
> Theoretically, that's not true.
>
> Good just-in-timing run core can run virtual machine code at almost the same
> speed as native code. And a good garbage-collector is faster than malloc/free
> (it pays some cost for surviving object, but for many short-lived objects, it
> is a lot faster) and compacts the working set, which improves cache
> performance. And these days, memory access cost as much as tens of
> instructions, so cache performance can make huge difference.
>
> Of course the cost of using garbage collector is bigger memory consumption,
> because the objects are not recycled immediately.
>
> --
>                                                 Jan 'Bulb' Hudec <bulb ucw cz>
> _______________________________________________
> vala-list mailing list
> vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list