realbasic-nug
[Top] [All Lists]

Re: High Performance Code (Was: Bitwise Shift operators)

To: REALbasic NUG <realbasic-nug at lists dot realsoftware dot com>
Subject: Re: High Performance Code (Was: Bitwise Shift operators)
From: Frank Condello <developer at chaoticbox dot com>
Date: Sat, 29 Sep 2007 15:58:42 -0400
Delivered-to: listarchive at realsoftware dot com
Delivered-to: realbasic-nug at lists dot realsoftware dot com
References: <BAY107-DAV8B16CCDB80BC51179695993B30 at phx dot gbl> <E9F3128F-A266-4A9B-8BAA-B4A5AF969AD4 at declareSub dot com>
Machine code is giberish to me, but feel free to take those sqrt  
approximations, compile, and dump away... Then come back and explain  
it to me ;)

Frank.
<http://developer.chaoticbox.com/>

On 29-Sep-07, at 3:22 PM, Charles Yeomans wrote:

> Perhaps you two could dump at the object code for the C and Rb source
> and we could see what the differences are.
>
> Charles Yeomans
>
> On Sep 29, 2007, at 3:13 PM, Daniel Stenning wrote:
>
>> This is exactly the issue. And its not as if RS discourages people
>> from
>> writing 3D Apps in RB. It provides plenty of framework and 3D
>> libraries as
>> if to encourage people to go down that path.
>>
>> Out of interest, just how much of that RB 3D app ends up being
>> written into
>> C++ RB plugins just to get the performance you require ?
>>
>>
>> On 29/9/07 20:02, "Frank Condello" <developer at chaoticbox dot com> wrote:
>>
>>> ---
>>> On 29-Sep-07, at 1:02 PM, Charles Yeomans wrote:
>>>
>>>> On Sep 29, 2007, at 12:26 PM, Norman Palardy wrote:
>>>>>
>>>>> What about getting rid of the bitshift ?
>>>>>
>>>>>    i = &h5f375a86 - (i/2)
>>>>
>>>> I tried this (actually i\2).  It saved a few ms, but that's it.
>>>
>>> Similar results here - it's definitely faster but still slower than
>>> the built-in sqrt wrapper.
>>>
>>> ---
>>> On 29-Sep-07, at 1:46 PM, Marco Bambini wrote:
>>>
>>>> What is fast for you?
>>>> I mean, how many Microseconds it should take the FastSqrt
>>>> function in
>>>> order to be "fast enough"?
>>>
>>> I'm not measuring a single call. In a real-world 3D app I have to
>>> normalize several thousand 3D vectors (among many other things) plus
>>> draw everything at (ideally) 60Hz. Normalizing the vectors in C code
>>> (loop and all) using an inlined sqrt approximation is far and beyond
>>> faster than anything I can muster in RB code - something in the  
>>> range
>>> of 20-30 times faster - no exaggeration. In this case "fast enough"
>>> is literally the difference between getting interactive framerates
>>> and watching a slideshow.





_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>


<Prev in Thread] Current Thread [Next in Thread>