Possibly, but the last time I had to work with assembler code was on the
Z80 ( Showing my age.... Sigh.. )
So I wouldn't be much use in reading the output.
There will be a performance tuning stage towards the end of this project
during which I ( or someone else ) will need to fine tune the performance to
eke out the last bit of "juice". At that stage I'll have to refresh on intel
assembler ( which has a link to the Z80 in its heritage ) and get my hands
dirty.
On 29/9/07 20:22, "Charles Yeomans" <charles at declareSub dot com> 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.
>>>
>>> Frank.
>>> <http://developer.chaoticbox.com/>
>>>
>>>
>>>
>>> _______________________________________________
>>> Unsubscribe or switch delivery mode:
>>> <http://www.realsoftware.com/support/listmanager/>
>>>
>>> Search the archives:
>>> <http://support.realsoftware.com/listarchives/lists.html>
>>>
>>
>> Cheers,
>> Dan
>>
>>
>>
>>
>> _______________________________________________
>> Unsubscribe or switch delivery mode:
>> <http://www.realsoftware.com/support/listmanager/>
>>
>> Search the archives:
>> <http://support.realsoftware.com/listarchives/lists.html>
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
>
Cheers,
Dan
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|