Jump to content

  • Log In with Google      Sign In   
  • Create Account

float unlimited increasing rotation or use a if


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
53 replies to this topic

#41 fir   Members   -  Reputation: -460

Like
0Likes
Like

Posted 02 January 2014 - 11:58 AM

 



Ok Simon, how about this one :

 

x = min( x , 100 );

 

or

 

if( x > 100 )x = 100;

 

And thank you Fir.

greetings

 

What about that one? What's the question?

 

Code clarity is almost the only thing that matters here, so use the one that most closely represents your intent.

 

For instance, if x is something that is computed in some way but we want to cap it from above for some reason, I would write

int capped_x = min(x, 100);

This is because it's easier to reason about the code if the meaning of a variable doesn't change through its lifetime, and if it has a descriptive name.

 

Do yourself a favor and stop thinking of micro-optimizations that won't make a difference.

 

 

I agree with that it is not important except of the tight processing

loops - but there maybe this is important but it leads to good level

of knowing assembly level code - the thing that i ew would like to

know and i would like to talk here with some asm knowing people 

but maybe they are hard to find today (also in www world there seem

to be hard to find good and easy materials /tutorials today learning

how to hand optymize procedures in asm 

 

as to opinions if this would result in general optymisations - some say no (and they belive compiler produce code better than you do) - some say yes (and they say that still compiler are silly to produce uneffective

code sometimes - 

 

I tend to belive the later in some special cases and the first in other (maybe most) cases

 

- but in general i think it is worth it to be interested in this thing (depending of the thing if you want to 'waste' the time on trying

to speed up procedures or no



Sponsor:

#42 ApochPiQ   Moderators   -  Reputation: 15737

Like
3Likes
Like

Posted 02 January 2014 - 12:02 PM

The point that those of us with assembly experience are trying to make is that those two code snippets are probably identical once compiled and optimized. Try it yourself and see.



#43 fir   Members   -  Reputation: -460

Like
0Likes
Like

Posted 02 January 2014 - 12:20 PM

The point that those of us with assembly experience are trying to make is that those two code snippets are probably identical once compiled and optimized. Try it yourself and see.

 

sure thats why i say it should be bringed to good level of asembly 'know-how' and maybe speaking more of choising of assembly opperands not c syntax(*) (and this is only important in suitable central loop cases you my never encounter or just dont care)

 

 

(*)  there was a topic recently about this things i was asking for

 

http://www.gamedev.net/topic/650824-x86-jumps-in-assembly/

 

(I am interested in such things though i got a little time to study it

very good :C )


Edited by fir, 02 January 2014 - 12:22 PM.


#44 Álvaro   Crossbones+   -  Reputation: 13322

Like
5Likes
Like

Posted 02 January 2014 - 12:33 PM

@ Madhed : What is meaned with high level optimalisation ?
something that is repeated 1000 times i am worrying about, if that is called low level optimalisation, then i am very confused.


"Level" means "height", and it's used metaphorical in many different ways. In one case "high level of optimization" refers to the compiler settings, where the different settings are called levels, and "high level" means "with most optimizations turned on". In the other case, worrying about the performance of some small piece of code inside a loop is called "low-level optimization", and here "level" refers to the abstraction level, where "low" means "close to the hardware" and "high" means "close to some human understanding of the situation, unconcerned with the details of how things are ultimately implemented".

A bunch of us here do know assembly language, and my knowledge of assembly language doesn't change my advice: You should write the code in the form that is most expressive. The compiler will generally do a very good job of mapping that into efficient code. If you have a program that is too slow and a profiler that tells you that you need to worry about how much time you are spending evaluating `min', you can try a few alternatives blindly to see what makes the program faster. Or, if you know some assembly language, you can look at the assembly output of your compiler and see if it is using conditional jumps; if that's the case, you can try to write the code in other ways where it might be easier for the compiler to realize that it can use conditional MOV instructions. If your hardware doesn't support conditional MOV instructions, you might be able to implement branch-less code yourself, doing something like this:
  unsigned mask = -(x > 100);
  mask &= (x ^ 100);
  x ^= mask;
I have changed code in critical parts of a program to avoid branches in the past, but you should only consider doing such things after the profiler tells you to. If you still haven't gotten that point by now, perhaps you are trolling us.

#45 the incredible smoker   Members   -  Reputation: 343

Like
-3Likes
Like

Posted 03 January 2014 - 04:58 AM

 

 

as to opinions if this would result in general optymisations - some say no (and they belive compiler produce code better than you do) - some say yes (and they say that still compiler are silly to produce uneffective

code sometimes - 

 

 

Why does the compiler make float to int as fast as the assembly code i got from www.musicdsp.org ?

So having ASM is needed in my opinion.

 

Also its very handy if you program microcontrollers.

 

 

 If you still haven't gotten that point by now, perhaps you are trolling us.

 

 

Look at your own picture ? lol.

 

greetings


S T O P   C R I M E !

Visual Pro 2005 C++ DX9 Cubase VST 3.70  Working on : LevelContainer class & LevelEditor


#46 fir   Members   -  Reputation: -460

Like
0Likes
Like

Posted 03 January 2014 - 05:40 AM

 

 

 

as to opinions if this would result in general optymisations - some say no (and they belive compiler produce code better than you do) - some say yes (and they say that still compiler are silly to produce uneffective

code sometimes - 

 

 

Why does the compiler make float to int as fast as the assembly code i got from www.musicdsp.org ?

So having ASM is needed in my opinion.

 

 

i do not understand the aboove question :u

 

as to float -> int casting

 

when i was using borland55 on pentium4 (i did it not so long time ago)

it had a terribly slow float->int conversions so i was even using nasm

like here

 

CastToInt:
  cvttss2si eax, dword [esp+4]
  ret
 
recently i am using mingw and I am not 100% sure but i think ALL (*) this kind of 'flops' are absent here - as far as i know mingw is producing inline scalar sse and somewhat well optymized code for such little
things as cast min sin etcetera
 
(*) someone correct me if Im wrong :U
 
on the other side, watching on example given in prewious thread I mentioned it was shown for example that when gcc (for some example code for minmax of three values) generated code with branches and cmov (but quite good quality ) clang generated longer code but with only the cmovs - one of this examples probably would be faster, then
someone gave third version with
__m128 minimum = _mm_min_ss(_mm_min_ss(a, b), c);

__m128 maximum = _mm_max_ss(_mm_max_ss(a, b), c);

commands
 
so for me it looks all like : mingw is probably producing qite good 
code, (no reason to be paranoid?) you probably could improve 
tight loops but then we should talk on specific assembly
operands level (that is what i vote for!  (becouse i would like to
find people able to talk about specific modern asm level
optymisations)


#47 Nanook   Members   -  Reputation: 505

Like
1Likes
Like

Posted 03 January 2014 - 08:04 AM

You are approaching programming the wrong way. Start by getting yourself some books on C++ and follow their advice. Start programming some simple games. Read more. Then when you start making more advanced games it might be natural to think of these kind of optimization (It probably wont be necessary though). By that time your Celeron CPU will be dead.

 

People on here have a lot of experience so do yourself a favor and listen to their advice.


Edited by Nanook, 03 January 2014 - 08:05 AM.


#48 the incredible smoker   Members   -  Reputation: 343

Like
0Likes
Like

Posted 03 January 2014 - 11:10 AM

Hi this is the code is use :

 

http://musicdsp.org/archive.php?classid=5#56

 

int truncate(float flt)
{
  int i;
  static const double half = 0.5f;
  _asm
  {
     fld flt
     fsub half
     fistp i
  }
  return i
}


S T O P   C R I M E !

Visual Pro 2005 C++ DX9 Cubase VST 3.70  Working on : LevelContainer class & LevelEditor


#49 BGB   Crossbones+   -  Reputation: 1554

Like
0Likes
Like

Posted 03 January 2014 - 11:32 AM

 

 

as to opinions if this would result in general optymisations - some say no (and they belive compiler produce code better than you do) - some say yes (and they say that still compiler are silly to produce uneffective
code sometimes - 

 
Why does the compiler make float to int as fast as the assembly code i got from www.musicdsp.org ?
So having ASM is needed in my opinion.

 

 
i do not understand the aboove question :u
 
as to float -> int casting
 
when i was using borland55 on pentium4 (i did it not so long time ago)
it had a terribly slow float->int conversions so i was even using nasm
like here
 
CastToInt:
  cvttss2si eax, dword [esp+4]
  ret
 
recently i am using mingw and I am not 100% sure but i think ALL (*) this kind of 'flops' are absent here - as far as i know mingw is producing inline scalar sse and somewhat well optymized code for such little
things as cast min sin etcetera
 
(*) someone correct me if Im wrong :U

 

IME: conversions between floating point numbers and integers are fairly expensive in general, so are better avoided when possible (in places where it matters, *).

 

a usual way to avoid this is, in cases where a lot of integer input/output is needed (such as in image-processing code), is to use a lot of fixed-point instead. or, if floating point numbers are used, to keep the process mostly using floating point.

 

 

*: "where it matters" is the important part. it is easy to spend lots of time micro-optimizing things that don't actually matter.

usually someone needs some other reason in this case (where it doesn't really matter), like: "have no idea for anything better to do, time to micro-optimize" or "want to get big looking numbers on a benchmark (for marketing reasons)" or similar.


Edited by BGB, 03 January 2014 - 11:32 AM.


#50 fir   Members   -  Reputation: -460

Like
0Likes
Like

Posted 04 January 2014 - 03:18 AM

Hi this is the code is use :

 

http://musicdsp.org/archive.php?classid=5#56

 

int truncate(float flt)
{
  int i;
  static const double half = 0.5f;
  _asm
  {
     fld flt
     fsub half
     fistp i
  }
  return i
}

 

quite fine, i could use it too (on oldcompilers), go on with that



#51 the incredible smoker   Members   -  Reputation: 343

Like
0Likes
Like

Posted 04 January 2014 - 10:20 AM

Maybe someone can explain the code to me ?,

how to make it for unsigned int ?

 

unsigned int truncate( float flt )


S T O P   C R I M E !

Visual Pro 2005 C++ DX9 Cubase VST 3.70  Working on : LevelContainer class & LevelEditor


#52 fir   Members   -  Reputation: -460

Like
0Likes
Like

Posted 04 January 2014 - 11:27 AM

Maybe someone can explain the code to me ?,

how to make it for unsigned int ?

 

unsigned int truncate( float flt )

 

those are the details, you should be sure if you want to dig such

details of maybe coding the gameplay 

 

as far as i know fpu has 4 rounding modes : to +inf , to -inf, to zero,

and rounding

 

rounding is the fpu default, but c float->int is defined as 'to zero' (truncation)

 

this code above takes float substracts 0.5 then stores int with rounding 

so this is working such way(if i am not mistaken, probably no)

 

1.3 -> 0.8 -> 1

1.8 -> 1.3 -> 1

-1.3 -> -1.8 -> -2

-1.8 -> -2.3 -> -2

 

so it seems that it emulates truncation only for int values > 0

 

probably floats from 0 to about 2 147 483 647 will be correctly converted

 

according to some info i found

 

"If the value being stored is too large for the destination format, is an infinity.gif, is a NaN, or is in an unsupported format and if the invalid-arithmetic-operand exception (#IA) is unmasked, an invalid-operation exception is generated and no value is stored in the destination operand. If the invalid-operation exception is masked, the integer indefinite value is stored in the destination operand."

 

if float would be bigger than about 2 147 483 647 no value would be stored in outpput int or "integer indefinite value " would be stored

which i do not know what is

 

so if you would use it for unsigneds or cast minus values it should be modified like

 

if (f<0) i = - truncate( -f );

 

and other faster algorithm used, same with larger unsigned 

values (i thing fistp for unsigneds is unavaliable in fpu instruction set i am not sure)

 

I was using cvttss2si which mean "Convert one single-precision floating-point number from xmm/m32 to one signed doubleword integer r32 using truncation." and is more effective i think, this 

instruction is avaliable in pentium4 and later - i was decided to use it along with other option use fist procedure for rounding 

 

RoundToInt:
  fld dword [esp+4]
  fistp dword [esp-4]
  mov eax, dword [esp-4]
  ret
 
attention, this procedure is probably wrong (i not noticed it back then only later) because i use low part of stack ([esp+4] is first argument [esp] is call return adres [esp-4] and more is unused stack but probably can be overvrited if some interrupt will appear - I am not sure because i do not know if interrupts are using the same stack as regular process
(probably no but i am not sure and this way of using down stack is like 'undocumented') :/ well maybe i will make a topic for that maybe someone will answer me


#53 the incredible smoker   Members   -  Reputation: 343

Like
0Likes
Like

Posted 04 January 2014 - 11:32 AM

Yeah, make topics until we are professor.


S T O P   C R I M E !

Visual Pro 2005 C++ DX9 Cubase VST 3.70  Working on : LevelContainer class & LevelEditor


#54 fir   Members   -  Reputation: -460

Like
0Likes
Like

Posted 04 January 2014 - 11:48 AM

Yeah, make topics until we are professor.

I am only moderately experienced (I think I need at least 5 (10?20?) years of work yet to be a professor ;/

 

this indefinite integer value is probably 80000000H,

 

cpu has many quirks so optymising the x86 is probably a work of lot of quirks to know


Edited by fir, 04 January 2014 - 12:08 PM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS