>No more comments on what you said below, I agree, maybe with an
>exception to the garbage collector thing - I made all possible
>references in my master's degree work program unowned, so that the
>bookkeeping should be reduced to minimum, and I gained 5% of
>performance. Well, I don't know if any
Hi,
please see some thinks inline,
>On Sat, Jan 15, 2011 at 22:53:25 +0100, Jiří Zárevúcky wrote:
>> 2011/1/15 Aleksander Wabik :
>> >> There are other relevant reasons to choose Vala over
>> >> C#, but speed is not one of them. :)
>> > This is... very sad. JIT is cool, because it helps to get ri
2011/1/15 Aleksander Wabik :
>
> Other thing: signals. Did someone measured their performance? I did
> once, its AWFUL! Why? Well, here we also are using highly reusable, and
> very slow code. Signals are referenced by name (yes, string!), signals
> get complicated marshallers for their parameters.
On Sat, Jan 15, 2011 at 22:53:25 +0100, Jiří Zárevúcky wrote:
> 2011/1/15 Aleksander Wabik :
> >> There are other relevant reasons to choose Vala over
> >> C#, but speed is not one of them. :)
> > This is... very sad. JIT is cool, because it helps to get rid of
> > performance problems introduced b
On Sat, Jan 15, 2011 at 20:56:45 +0100, Jan Hudec wrote:
> On Sat, Jan 15, 2011 at 19:58:37 +0100, Marco Trevisan (Treviño) wrote:
> > However I don't think that an atomic add or fetch-and-add (or
> > call them inc and dec-and-test) correctly used in plain C wouldn't cause
> > all this performance
2011/1/15 Aleksander Wabik :
>> There are other relevant reasons to choose Vala over
>> C#, but speed is not one of them. :)
>
> This is... very sad. JIT is cool, because it helps to get rid of
> performance problems introduced by some features of OOP, but if we are
> compiling to C, should we not
We are pleased to announce version 0.11.4 of Vala, a compiler for the
GObject type system.
Vala 0.11.4 is now available for download at:
http://download.gnome.org/sources/vala/0.11/
This is a development release leading toward 0.12.
Changes since 0.11.3
* Add index_of, index_of_char, and cha
On Sat, Jan 15, 2011 at 19:58:37 +0100, Marco Trevisan (Treviño) wrote:
> Il giorno sab, 15/01/2011 alle 19.09 +0100, Jiří Zárevúcky ha scritto:
> > >
> > > Yes, it's not the same, but it's a similar implementation, using
> > > reference counting (it's not atomic, but if you use an sig_atomic_t ref
> There are other relevant reasons to choose Vala over
> C#, but speed is not one of them. :)
This is... very sad. JIT is cool, because it helps to get rid of
performance problems introduced by some features of OOP, but if we are
compiling to C, should we not try to solve these problems on another
Il giorno sab, 15/01/2011 alle 19.09 +0100, Jiří Zárevúcky ha scritto:
> >
> > Yes, it's not the same, but it's a similar implementation, using
> > reference counting (it's not atomic, but if you use an sig_atomic_t ref
> > variable, instead of the volatile int, you would get atomicity with no
> >
Il giorno sab, 15/01/2011 alle 19.20 +0100, Jiří Zárevúcky ha scritto:
>
> By the way.. "evil"? puh-lease... Technology itself can never be evil.
> It's always people. Don't spread hate on this list while I'm reading
> it.
I was just jocking... Sorry, I'm not against that world... But since I
gue
On Fri, Jan 14, 2011 at 5:28 PM, Marco Trevisan (Treviño)
wrote:
> [...]
> I guess that a gobject structure is really more complex compared to the
> ones defined by Dova (or by simple C), but if Vala has these
> performances, due to GObject mamangement, even the (evil) Mono C# seems
> to be better
>
> Yes, it's not the same, but it's a similar implementation, using
> reference counting (it's not atomic, but if you use an sig_atomic_t ref
> variable, instead of the volatile int, you would get atomicity with no
> performance loss at all),
Not true I believe. sig_atomic_t ensures atomicity on
13 matches
Mail list logo
