Re: [Vala] benchmarks on Vala?
On 01/18/11 01:54, Andrés G. Aragoneses wrote: On 17/01/11 14:08, Jiří Zárevúcky wrote: On Mon, Jan 17, 2011 at 1:24 AM, Didip Kerabatdid...@gmail.com wrote: I don't know about any recent benchmarks, but I think Vala will generally be a bit slower than Mono, but more memory efficient. Slower, really? Would that be true as well for the dova profile? i think (not demonstrated) that vala is faster than mono on normal situations where you don't build over nine thousand objects per second. ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] benchmarks on Vala?
you should post this in a new thread. the language looks interesting, but I would prefer lispy parenthesis than brackets. it hurts less my eyes. Few time ago I proposed in the irc(?) about adding a lispy/schemy syntax support to Vala. I think Gel does the job, but I would like to have it inside Vala and using () syntax. --pancake On 01/18/11 21:26, Sandino Flores Moreno wrote: 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 5] [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 Hudecb...@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' Hudecb...@ucw.cz ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] benchmarks on Vala?
I second that. In typical scenarios, where you are not creating hundreds of thousands GLib.Objects all the time, you will have much faster applications with vala. On 01/18/11 01:54, Andrés G. Aragoneses wrote: On 17/01/11 14:08, Jiří Zárevúcky wrote: On Mon, Jan 17, 2011 at 1:24 AM, Didip Kerabatdid...@gmail.com wrote: I don't know about any recent benchmarks, but I think Vala will generally be a bit slower than Mono, but more memory efficient. Slower, really? Would that be true as well for the dova profile? i think (not demonstrated) that vala is faster than mono on normal situations where you don't build over nine thousand objects per second. ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Gel: Glib-Embedded-Language
Hi again, I've been reading a bit more of gel. I thought it was generating C code, but it is interpreted, so it takes no sense to merge it in Vala. But I still think that having a lispy syntax for Vala would be great. About brackets vs parenthesis. You say in README that you choose [] because they are easier to type. Thats not true at all, it depends on the keyboard and the layout. it's ok for a PC keyboard with english layout, but not for spanish for example, and on smartphone keyboards () are more accessible than []. And for readability I think that () looks better than []. I would love to see a REPL interface in Gel. Nice work :D the idea of being able to access any objects from a running application using a GObject-based lisp-like language sounds great. --pancake On 01/18/11 21:26, Sandino Flores Moreno wrote: 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 5] [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 Hudecb...@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' Hudecb...@ucw.cz ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] V4l2 - STREAMON Fails
Hello,
Anyone who have knowledge in using the V4l2 interface? Specifically someone
who have worked on Webcam, with STREAMING capability, using vala?
Heres the problem:
I was able to setup my webcam with the help of sample in
http://v4l2spec.bytesex.org/spec/a16706.htm. Everything was going smoothly
until im ready to IOCTL using VIDIOC_STREAMON. I have already checked every
possible cause of the error described in
http://v4l2spec.bytesex.org/spec/r13817.htm as follows:
On success 0 is returned, on error -1 and the errno variable is set
appropriately:
EINVAL
Streaming I/O is not supported, the buffer type is not supported, or no
buffers have been allocated (memory mapping) or enqueued (output) yet.
The following error is being returned by the compiler:error: 'BufferType'
undeclared (first use in this function).
But i didn't modify any part of V4l2.vapi.
One thing i noticed in the converted c code are following lines:
...
BufferType type = 0;
...
type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
if (ioctl (self-priv-fd, VIDIOC_STREAMON, type) == (-1)) {
}
...
Why is the BufferType not converted to something like
enum v4l2_buf_type?
and should the parameter type in my ioctl be prepended with , thus
making it type?
Help please!
Thanks!
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] benchmarks on Vala?
Exactly, that's why I mentioned my specific experience with my pet language, because I was in the case that for every iteration, I was creating 2 gobjects, which resulted in 100,000 gobjects created in a few seconds. And just dropping gobjects (full classes) to use plain structs (compact classes) saw an improvement of 300%. GLib (and therefore Vala) provide many options that seem redundant at first glance until you realize their advantages (full classes, compact classes, boxed types, references over copies, etc). On Wed, Jan 19, 2011 at 4:39 AM, JM interfl...@gmx.net wrote: I second that. In typical scenarios, where you are not creating hundreds of thousands GLib.Objects all the time, you will have much faster applications with vala. On 01/18/11 01:54, Andrés G. Aragoneses wrote: On 17/01/11 14:08, Jiří Zárevúcky wrote: On Mon, Jan 17, 2011 at 1:24 AM, Didip Kerabatdid...@gmail.com wrote: I don't know about any recent benchmarks, but I think Vala will generally be a bit slower than Mono, but more memory efficient. Slower, really? Would that be true as well for the dova profile? i think (not demonstrated) that vala is faster than mono on normal situations where you don't build over nine thousand objects per second. ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Gel: Glib-Embedded-Language
Thanks Pancake. Agree, I'll drop the [ ] to use ( ) I have not announced it yet because I still have problems returning lambdas, and also because I do not have introspection yet (just a snippet to play around) (And also because my wife is back from vacation, which means I have less spare time. He he!!) AhhI forgot to mention that it provides a .vapi, and an example in Vala. Actually, I tried to write it in Vala, but C was more convenient because it allows more control. On Wed, Jan 19, 2011 at 5:46 AM, pancake panc...@youterm.com wrote: Hi again, I've been reading a bit more of gel. I thought it was generating C code, but it is interpreted, so it takes no sense to merge it in Vala. But I still think that having a lispy syntax for Vala would be great. About brackets vs parenthesis. You say in README that you choose [] because they are easier to type. Thats not true at all, it depends on the keyboard and the layout. it's ok for a PC keyboard with english layout, but not for spanish for example, and on smartphone keyboards () are more accessible than []. And for readability I think that () looks better than []. I would love to see a REPL interface in Gel. Nice work :D the idea of being able to access any objects from a running application using a GObject-based lisp-like language sounds great. --pancake On 01/18/11 21:26, Sandino Flores Moreno wrote: 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 5] [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 Hudecb...@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' Hudecb...@ucw.cz ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] benchmarks on Vala?
It is well known thing in C++ that calling a new for creating a new classes costs. Especially framework classes (i.e. root.cern.ch) with virtual table and probably reloaded new operator (but still based on malloc heap allocation) gains approximately the same performance on creation as was shown for VALA in this thread. So if you need to have empty objects fast (for example in loops) you should better not to create but clear and reuse. If you really need to populate your memory with 100,000 objects, you'd better to have as few as possible memory allocation times. Have somebody tried creating this objects not one by one but in arrays? But in normal programming the overhead of creating the new objects vs. reusing old ones usually is less than 4%. For the .NET C# (should be same for Mono) new operation is not based on malloc heap allocation, but is based on allocation from some buffer called managed heap. So the new operation is really fast for .NET C#. If you will use .Clear() method of your class while C# users call new you will beat C#. Good article about memory allocation http://msdn.microsoft.com/en-us/magazine/bb985010.aspx (part 1) http://msdn.microsoft.com/en-us/magazine/bb985011.aspx (part 2) article on how much things costs http://msdn.microsoft.com/en-us/library/ms973852.aspx Some article on garbage collector performance http://msdn.microsoft.com/en-us/library/ms973837.aspx This managed heap is preallocated, but in case of malloc you always get the amount of memory you need. Thus you can see but more memory efficient. It is not really efficiency for long term software living because managed heap may grow or shrink depending on memory usage. In real project one can gain efficiency in this only if one will pay much much attention to this. 2011/1/19 pancake panc...@youterm.com On 01/18/11 01:54, Andrés G. Aragoneses wrote: On 17/01/11 14:08, Jiří Zárevúcky wrote: On Mon, Jan 17, 2011 at 1:24 AM, Didip Kerabatdid...@gmail.com wrote: I don't know about any recent benchmarks, but I think Vala will generally be a bit slower than Mono, but more memory efficient. Slower, really? Would that be true as well for the dova profile? i think (not demonstrated) that vala is faster than mono on normal situations where you don't build over nine thousand objects per second. ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Unexpected behaviour when using interfaces.
Hi list.
This is my first time posting here, so bare with me if I'm being an idiot.
I apologize for continuing with the performance discussion but I've noticed
unintuitive (at least to me) behaviour when using interfaces in Vala.
I know that calling interface methods is expensive and that it's a known issue
in GLib but there is another problem. When a class implements an interface,
calling methods is slow regardless whether you declare your objects as being
instances of the class or the interface.
I attached a simple example that demonstrates the problem.
Object1 implements the interface directly and it doesn't matter whether we
declare our object as Interface or Object1, both are slow.
Object1 through interface : 18.620215
Object1 directly : 18.767607
Object2 does not implement Interface directly but inherits form AbsObject
(which in this case is abstract but it could also be a regular class). which in
turn implements Interface, now only the instance declared as Interface is
slower.
Object2 through interface : 18.902430
Object2 directly : 2.987541
Looking at the generated C code it seems to be a side effect of the way vala
handles inheritance but I don't have enough experience with GObject to judge.
So my question would be whether this is intentional, maybe I'm missing
something?
If it is then interfaces have to be used even more carefully and you need to use
a dummy class in between the interface just to be able to use your class without
the extra overhead when the interface is not needed.
Regards, Sergej
int main() {
int num_iterations = 3;
Profiler p;
Interface ob1_interface = new Object1(0);
p = new Profiler(Object1 through interface);
for(int i = 0; i = num_iterations; i++) {
ob1_interface.add(i);
}
p = null;
Object1 ob1_directly = new Object1(0);
p = new Profiler(Object1 directly );
for(int i = 0; i = num_iterations; i++) {
ob1_directly.add(i);
}
p = null;
Interface ob2_interface = new Object2(0);
p = new Profiler(Object2 through interface);
for(int i = 0; i = num_iterations; i++) {
ob2_interface.add(i);
}
p = null;
Object2 ob2_directly = new Object2(0);
p = new Profiler(Object2 directly );
for(int i = 0; i = num_iterations; i++) {
ob2_directly.add(i);
}
p = null;
stdout.printf(\n);
return 0;
}
public interface Interface : Object {
public abstract void add(int i);
}
public abstract class AbsObject : Interface, Object {
public abstract void add(int i);
}
public class Object1 : Interface, Object {
private int val;
public Object1(int i) {
this.val = i;
}
public void add(int i) {
this.val += i;
}
}
public class Object2 : AbsObject {
private int val;
public Object2(int i) {
this.val = i;
}
public override void add(int i) {
this.val += i;
}
}
public class Profiler {
private string description;
private Timer t;
public Profiler(string description) {
this.description = description;
t = new Timer();
t.start();
}
~Profiler() {
t.stop();
stdout.printf(%s : %lf\n, description, t.elapsed());
}
}
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] functions and null
Hi, why this code doesn't work
Item item = null;
parse_content(item);
parse_content(Item item) {
stderr.printf(argh);
}
reports
** (process:674): CRITICAL **: xml_parser_parse_content: assertion
`item != NULL' failed
signature.asc
Description: This is a digitally signed message part
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] functions and null
2011/1/19 Pavol Klačanský pa...@klacansky.com:
Hi, why this code doesn't work
Here the item is null
Item item = null;
parse_content(item);
And in this function you declared parameter as non-null
parse_content(Item item) {
stderr.printf(argh);
}
reports
** (process:674): CRITICAL **: xml_parser_parse_content: assertion
`item != NULL' failed
Unlike Java and other languages Vala has idea of nullable references.
You should declare your function as
parse_content(Item? item) {
pay attention to the question mark after the parameter type.
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] functions and null
On Wed, 2011-01-19 at 22:11 +0100, Pavol Klačanský wrote:
Hi, why this code doesn't work
Item item = null;
parse_content(item);
parse_content(Item item) {
stderr.printf(argh);
}
reports
** (process:674): CRITICAL **: xml_parser_parse_content: assertion
`item != NULL' failed
This doesn't work because Vala automatically adds an assertion to check
if function parameters are null. This behavior is the standard for GLib
programs.
If you would like to pass a null value into a function, try (untested):
void parse_content(Item? item) { ... }
The question mark makes the variable 'nullable' meaning that it is
allowed to be null.
I hope that helps,
Sam
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Unexpected behaviour when using interfaces.
On Wed, 2011-01-19 at 21:52 +0100, Sergej Reich wrote: I know that calling interface methods is expensive and that it's a known issue in GLib but there is another problem. When a class implements an interface, calling methods is slow regardless whether you declare your objects as being instances of the class or the interface. [...] So my question would be whether this is intentional, maybe I'm missing something? If it is then interfaces have to be used even more carefully and you need to use a dummy class in between the interface just to be able to use your class without the extra overhead when the interface is not needed. Vala follows common GLib practice where possible and in the case of interface implementations, it's common practice to not export the method implementations directly and always use the interface wrapper functions instead. I understand that this may be a performance issue, however, deviating from common practice in that regard would work only with classes written in Vala and require many annotations in bindings of GLib/C libraries as they usually do not support direct calls. That's why I'd like to keep it the way it is. The plan for the Dova profile is to allow direct access to the method implementations for performance and other reasons. Jürg ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Unexpected behaviour when using interfaces.
On Wed, 2011-01-19 at 22:46 +0100, Jürg Billeter wrote: On Wed, 2011-01-19 at 21:52 +0100, Sergej Reich wrote: I know that calling interface methods is expensive and that it's a known issue in GLib but there is another problem. When a class implements an interface, calling methods is slow regardless whether you declare your objects as being instances of the class or the interface. [...] So my question would be whether this is intentional, maybe I'm missing something? If it is then interfaces have to be used even more carefully and you need to use a dummy class in between the interface just to be able to use your class without the extra overhead when the interface is not needed. Vala follows common GLib practice where possible and in the case of interface implementations, it's common practice to not export the method implementations directly and always use the interface wrapper functions instead. I understand that this may be a performance issue, however, deviating from common practice in that regard would work only with classes written in Vala and require many annotations in bindings of GLib/C libraries as they usually do not support direct calls. That's why I'd like to keep it the way it is. The plan for the Dova profile is to allow direct access to the method implementations for performance and other reasons. Jürg Thank you for the clarification, of course consistency with other GLib code is more important. My main concern then would be with libraries like Gee. Right now all the classes are implemented through abstract classes so the mentioned problem is not noticeable but if Gee would use the interfaces directly this would probably change. Regards, Sergej ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
