|
you find this elegant ?????????
i agree the ?: operator is elegant when you have few (less than 2) conditions, but it becomes really unreadable otherwise.
more, it uses exactly the same time as the previous post's code. what i prefer is expanding the code, but placing the { }. it doesn't eat bread and it is really more easy to debug.
one last thing. the first written code is (by my thinking quite fast). you can so let it like this :
<font style="color:blue;">if </font>(a > 0) {
<font style="color:blue;">if </font>(a > 255) {
b = 255;
}
<font style="color:blue;">else</font> {
b = (BYTE)a;
}
}
<font style="color:blue;">else </font>{
b = 0;
}
TOXCCT >>> GEII power
|
|
|
|
|
|
Nitron wrote:
I see you are a same-line bracer
where, which ? what is wrong in my code ?
i don't exactly understand your sentence. could you rephrase it please ?
TOXCCT >>> GEII power
|
|
|
|
|
You do this:
if (a > 0) {
if (a > 255) {
b = 255;
}
else {
b = (BYTE)a;
}
}
else {
b = 0;}
instead of this:
if (a > 0)
{
if (a > 255)
b = 255;
else
b = (BYTE)a;
}
else
b = 0;
i.e. you put your opening braces on the same line as your conditional statement.
~Nitron.
ññòòïðïðB A
start
|
|
|
|
|
and so what ??? didn't you ever saw that ?? is it a code fault ? pfffffff poor guy.
moreover, i said that it was more readable to write the code with the braces. when you cat multiple if statements, we are not sure to whose if the esle is associated with.
My code is correct, if you don't like this, it's your point of view, but it is efficient !
TOXCCT >>> GEII power
|
|
|
|
|
dude, chill. The code is fine, I was just giving you a hard time. I guess I know how to push your buttons 
~Nitron.
ññòòïðïðB A
start
|
|
|
|
|
If you can also provide us with the data types of a and b, then may be we can find out some idea. And if you can explain what you are actually trying to do, that would be much better.
Gurmeet
BTW, can Google help me search my lost pajamas?
My Articles: HTML Reader C++ Class Library, Numeric Edit Control
|
|
|
|
|
b is BYTE, a is float.
I'm making convolution of 2 matrix. they are BYTE type. So i need to control bounds.
|
|
|
|
|
|
|
No! its useless 
|
|
|
|
|
he asked for fast, not undebugable unreadable useless code 
TOXCCT >>> GEII power
|
|
|
|
|
If you really think optimizing this code is worth the effort, you couldn't be more wrong. For a detailed analysis on this topic, see this article. I'm not saying that it isn't possible, but in the grand scheme of things, saving a handful of operations is pointless.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
If these lines of code are taking most of the time and the algorithm is correct, then yes, he should look at these lines.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Try:
b = (BYTE)a;
(void)(!(a > 0xFF)||((b = 0xFF)));
|
|
|
|
|
|
Chances are most of your time is spent in "b = (BYTE) a". This is probably using "ftol" which is very slow.
Because of the C/C++ standard, the ftol must change the FPU settings before and after converting the value to an integer. Thus there is a LOT of wasted time.
Search google for "fast ftol".
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
I agree it definately will be this conversion.
Ant.
|
|
|
|
|
I have seen this kind of problem before, where when manipulating matrix values, an inordinate amount of time is spent during the conversion of data types: floats to ints, for example. I hope your compiler isn't keeping "255" as an int and converting it to "255.0f" for every comparison. Certainly the compiler should be smarter than that.
If all the "a" values are floats, then your conversion to BYTE doesn't maintain any of the decimal portions of the "a" values. Therefore, why does "a" need to be a float? Could everything else be made to work properly if "a" was not a float?
You may also consider a simpler comparison structure that eliminates the "else" statements. Using "else" complicates the control flow, such that during a pre-fetch lookup, the CPU can't know which path it is going to take. When I was writing code for a DSP, this was a big concern. A statement like if (a < 0) b = 0; was able to be optimized better than if (a > 0) {...} else b = 0; because of the single statement (not a block) and not having an "else". I don't know if this strategy will help you on a normal PC.
Depending on the constraints on "b", you could try:
b = (BYTE) a;<br />
if (a < 0.0f) b = 0;<br />
if (a > 255.0f) b = 255;
At least on a DSP, while it seems that a test may be performed unnecessariyly, it was actually faster because of the improvements in control flow.
I don't know what tool you are using to test your performance, but you may want to try the Memory Validator that is advertised here on CodeProject.
Good luck.
Dave
"You can say that again." -- Dept. of Redundancy Dept.
|
|
|
|
|
With the above proposition you are always executing
b = (BYTE) a;
This is the bottleneck within the code segment. I know it will all depend on the values of a as to how relevant this would be, but it is a factor.
Ant.
|
|
|
|
|
Over and above what other people have said one other thing to check is:
Ensure that the code that does this is executed the correct number of times in order to get the result. I have come across code that had superfulous executions, this obviously is a quick win fix.
Ant.
|
|
|
|
|
if (a > 0)
{
if (a > 255)
b = 255;
else
b = (BYTE)a;
}
else
b = 0;
This is what you are attempting to accomplish?
Number of Instructions != speed, btw.
However, if you really want to optimize it that bad I would write it directly in assembly yourself.
The assembly generated by any proposed solultion will also depend on the compiler options and the surrounding code. So, you can't trust what someone else says is smaller for them obviously because they can be optimized differently depending on the surrounding code.
Here's some examples:
DWORD func(DWORD b, DWORD a)
{
if (a > 0)
{
if (a > 255)
b = 255;
else
b = (BYTE)a;
}
else
b = 0;
return b;
}
DWORD func2(DWORD b, DWORD a)
{
if(b = a)
{
if(a > 255) // if a was a WORD, if (a & 0xFF00) faster?
{
b = 255;
}
else
{
b &= 0xFF;
}
}
return b;
}
DWORD func3(DWORD b, DWORD a)
{
if(b = a)
{
b &= 0xFF;
if(a > b)
{
b = 255; // or is "b |= 255 faster?"
}
}
return b;
}
DWORD func4(DWORD b, DWORD a)
{
b = 0;
if(a)
{
if(!(b = a & 0xFF))
{
b = 255; // or is "b |= 255 faster?"
}
}
return b;
}
assembly:
func:
004012b0 8b442408 mov eax,[esp+0x8]
004012b4 85c0 test eax,eax
004012b6 7617 jbe dptest!func+0x1f (004012cf)
004012b8 3dff000000 cmp eax,0xff
004012bd 7608 jbe dptest!func+0x17 (004012c7)
004012bf b8ff000000 mov eax,0xff
004012c4 c20800 ret 0x8
004012c7 25ff000000 and eax,0xff
004012cc c20800 ret 0x8
004012cf 33c0 xor eax,eax
004012d1 c20800 ret 0x8
func2:
004012e0 8b442408 mov eax,[esp+0x8]
004012e4 85c0 test eax,eax
004012e6 7414 jz dptest!func2+0x1c (004012fc)
004012e8 3dff000000 cmp eax,0xff
004012ed 7608 jbe dptest!func2+0x17 (004012f7)
004012ef b8ff000000 mov eax,0xff
004012f4 c20800 ret 0x8
004012f7 25ff000000 and eax,0xff
004012fc c20800 ret 0x8
As you can see, the assembly was optimized to not penalize for A = B in the first if. That's because we're returning the end result, so we can have it optimized.
func3:
00401300 8b4c2408 mov ecx,[esp+0x8]
00401304 85c9 test ecx,ecx
00401306 8bc1 mov eax,ecx
00401308 740e jz dptest!func3+0x18 (00401318)
0040130a 25ff000000 and eax,0xff
0040130f 3bc8 cmp ecx,eax
00401311 7605 jbe dptest!func3+0x18 (00401318)
00401313 b8ff000000 mov eax,0xff
00401318 c20800 ret 0x8
func4:
00401320 8b4c2408 mov ecx,[esp+0x8]
00401324 33c0 xor eax,eax
00401326 85c9 test ecx,ecx
00401328 740f jz dptest!func4+0x19 (00401339)
0040132a 81e1ff000000 and ecx,0xff
00401330 8bc1 mov eax,ecx
00401332 7505 jnz dptest!func4+0x19 (00401339)
00401334 b8ff000000 mov eax,0xff
00401339 c20800 ret 0x8
|
|
|
|
|
I really don't know why you want to optimize this code!?
give me the whole code of the function.
Don't try it, just do it! 
|
|
|
|
|
Most time takes b=(BYTE)a . And it is impossible to make it works faster.
|
|
|
|
|
Please read my response. You can make "b = (BYTE) a " a LOT faster. It involves using a "fast ftol". Search google for that phrase.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
the horror! I'd much rather wade through deeply obfuscated code than to subject my tender eyes to such bracing schemes...