Extending RGSS (ruby) with C

[FenixFyreX]

You can check out benchmark-ips here, it's pretty accurate; a lot of Rubyists use it to benchmark things, and as you can see, it's quite popular just on github; it's recommended around the Ruby forums and such as well.


The numbers are there, whether you choose to believe them or not The overhead of parsing through Ruby is that slow as compared to a C Extension. Ruby is an interpreted language...this is just something you'll have to accept.


If you feel like benchmark-ips is flawed (which it isn't), then you can always use a different benchmark tool, such as the SES version floating around, on the anagram solver I posted. It'll most likely give similar results

 

[Tsukihime]

The overhead of parsing through Ruby is that slow as compared to a C Extension. Ruby is an interpreted language..

I'm talking about your DLL vs SO numbers, not Ruby vs C.

Your first benchmark showed that native C extensions run 20x faster than native C libraries.

This would suggest that if the benchmark is accurately measuring how many iterations the DLL is running, that the DLL is doing a lot of unnecessary things. If it's performing type-checks everytime it does something, then that may explain why it's so much slower. For example, if I tell it to add 1 to 10 in a loop

int sum_upto(int { int sum = 0 for (int i = 0; i < b; i++) { sum++; // but instead of just incrementing by 1, we also error check } return sum;}and everytime it performs an add operation it needs to make sure that ruby isn't going to complain, that's a lot of extra overhead.Am I misunderstanding what the benchmark is showing?

 

[FenixFyreX]

I know; I'm talking about the DLL vs SO as well; have you ever looked at the code that makes up Win32API / DL? It is (mostly) written in Ruby, as well as DL. That is, and always will be, slower than using direct C function calls exposed by a C extension.

And no, my first benchmark showed that native C extensions run 20x faster than calling native C libraries through Ruby and an underlying C extension. It also had no type checking whatsoever. Win32API has internal type checking of it's own that you can't remove, and that is the bottleneck right there.

Think of it this way:

Object.some_c_extension_method# Execution stack: Look up method name in method table, call function pointer# from said method table.# This is pretty much the equivalent of referencing an# instance of Method in an array, executing that method, then returning the result.# Except faster, cause it's done C-side.SomeApiFunc.call(*vars)# Execution stack: Send vars array to be parsed Ruby-side, a string to be iterated# through Ruby-side, vars array is then passed C-side to be interated through and# converted, then the Win32API function is referenced from an internal list C-side,# then it is called C-side, and the result is converted to a Ruby object via a# Ruby-side string prototype, then the result is returned.TL;DR: Win32API and DL have Ruby boilerplate code, which is what is slowing it down. You do not directly call a native C function with Win32API / DL; with a Ruby C Extension method, you do. I think you are confused as to how Win32API and DL works, exactly.Note that both means of accessing C functions have a small amount of overhead of Ruby parsing the mehod call, no matter the means. Excluding that, A C Extension is pretty much equivalent to directly calling a C function. You have them backwards

EDIT: And, as a bonus, I can guarantee that writing a C extension that calls any Win32API function from a windows dll will be significantly faster than using Win32API, simply because of said boilerplate code, written in Ruby.

EDIT2: Sorry for the clusterfu** that is this post; I'm dealing with a little one at the moment, she just got home from school. I'll clean it up / better explain in a bit.

 

[??????]

Perhaps worth noting the differences in using a normal ruby extension compared to an extension used in an rpg maker environment.  ^_^

You can likely explain that better than I

 

[Tsukihime]

And no, my first benchmark showed that native C extensions run 20x faster than calling native C libraries through Ruby and an underlying C extension. It also had no type checking whatsoever. Win32API has internal type checking of it's own that you can't remove, and that is the bottleneck right there.

Oh, ok I was under the impression that your benchmark demonstrated how DLL's performed 20x poorer than using an SO since both tests make a single call to each function and for some reason one of them just ran 20x slower (ie: ran so much less iterations per second) to solve the same problem.


So basically when the DLL function is running, win32API is still sticking checking every operation (ie: internal type checking) instead of just letting the DLL finish its work before checking whether the final result is ok for ruby. This would account for the extra overhead per iteration, resulting in the 20x difference per iteration of the DLL function.


EDIT: I see the problem in my logic. I'm still thinking that the benchmark was simply testing how fast the DLL was running, and not taking into consideration all the extra ruby stuff. The term "iteration" was confusing me because I see that the method is being called once, and the only thing that seems to be iterating to me was the actual anagram solving function.