question for hppl compiler people
|
11-13-2017, 10:20 AM
Post: #1
|
|||
|
|||
question for hppl compiler people
If I declare a variable as:
LOCAL A:=#0d32; vs LOCAL A:=0.; Does the first declaration result in operations involving such variables being compiled to integer operations and the second declaration result in operations compiled to floating point operations? ....or...is everything converted to a common format (like real or int) and everything done using that format? I was trying a few operations in a big loop and the timing seems to be the same regardless of the declaration, which probably means it's all done in floating point format since there isn't a hardware FPU in the ARM chip....integer would be faster if there was a difference. Let me know if any of you are familiar with the compiler internals... Thx -Donald |
|||
11-13-2017, 11:04 AM
Post: #2
|
|||
|
|||
RE: question for hppl compiler people
(11-13-2017 10:20 AM)webmasterpdx Wrote: integer would be faster if there was a difference. You've answered your own question! Tom L Cui bono? |
|||
11-13-2017, 02:58 PM
Post: #3
|
|||
|
|||
RE: question for hppl compiler people
You have what is called HP_Real values internally which are BCD encoded floats. Then you have HP_Int which is an integer encoded 64 bit object.
HP_Int will most likely be slightly faster, but to the point of negligence. There are generally more checks and Reals will be checked for and handled first in the trees. TW Although I work for HP, the views and opinions I post here are my own. |
|||
11-14-2017, 10:09 AM
Post: #4
|
|||
|
|||
RE: question for hppl compiler people
I guess I'm asking can we through declaration, control which is being used? e.g. Lets say it's using floats by default and I want to do some numeric search/algorithm using bytes only, so I define a variable as #0d8 or something like that. Is there a way to speed up the algorithm by forcing integer instead of float arithmetic?
Thx |
|||
11-14-2017, 03:57 PM
Post: #5
|
|||
|
|||
RE: question for hppl compiler people
Both TYPE(0.) and TYPE(0) return 0 (HP_real) whereas TYPE(#0d) returns 1 (HP_int)
So you already have a mechanism for declaring the types. Graph 3D | QPI | SolveSys |
|||
11-14-2017, 08:58 PM
Post: #6
|
|||
|
|||
RE: question for hppl compiler people
(11-13-2017 02:58 PM)Tim Wessman Wrote: You have what is called HP_Real values internally which are BCD encoded floats. Then you have HP_Int which is an integer encoded 64 bit object. Tim, I am sure you meant negligibility Stephen Lewkowicz (G1CMZ) https://my.numworks.com/python/steveg1cmz |
|||
11-15-2017, 05:11 AM
Post: #7
|
|||
|
|||
RE: question for hppl compiler people
Han, so when I have:
LOCAL A:=#0d32; etc.. Then if I have an algorithm using such variables, can I assume it's using integer arithmetic? I'll try to create a test of this when I get a chance and implement it in a loop with both floats and integers....ideally I should get different results. My previous test just called PIXON_P to fill the screen. It's possible that that isn't enough....I'll try to create just a few arithmetic statements and avoid the function calls. There is an obvious conversion on a function call that makes the water murky. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: