Actually - I've just remembered - even that isnt it.
I did a rerun earlier where I simply commented out the code inside the
nested loops. This would eliminate any issues due to virtual method calls.
Naturally the timings fell for both RB and C. But to my surprise RB was
STILL around 9 times slower than C !.
So for the RB PTR case I used:
dim u as integer = Count * 4
for j as integer = 0 to iterations
for i as integer = 0 to u step 4
// pB.Single(i) = pA.Single(i)
Next
Next
And in C dylib:
void copySingle (int count, float * A, float * B ) {
int i;
for ( i = 0; i < count ; i++ ) {
// B[i] = A[i];
}
};
On 16/5/07 15:57, "Daniel Stenning" <[EMAIL PROTECTED]> wrote:
> I think you are making excuses for RB. For Sure my C code isnt written to
> do that, simply because I wrote the simplest and fastest C code I could
> think of to do the same task as I want to achieve in RB. Why should I want
> to make my C code artificially slower to do a very common task? The whole
> point of all this is I want to use RB - not C.
>
> Tell me exactly how to code this in RB alone to speed things up and I will
> be happier.
>
> I might take your suggestion up though just to clear up this issue and post
> the results here.
>
>
>
> On 16/5/07 15:44, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
>>
>> Change your C code to C++ code that calls a virtual method to get a
>> value out of the array, and another to stuff a new value in, and I bet
>> the performance will be similar to RB.
>
> Regards,
>
> Dan
>
>
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
>
Regards,
Dan
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
