How to make code block works faster?

gUrM33T

or may be this: b = (a > 255 : 255 : (a <= 0 ? 0 : (BYTE)a)); Gurmeet

BTW, can Google help me search my lost pajamas?

My Articles: HTML Reader C++ Class Library, Numeric Edit Control

Diddy

Try: b = (BYTE)a; (void)(!(a > 0xFF)||((b = 0xFF)));

Kolich

No! its useless :(

Nitron

Kolich wrote: This block processing takes 3/4 of all code time. :omg: no way! (unless your total processing time is like 0.000012 seconds). How long is your processing time? How many elements in your matrix? Here is the disassembly for my test block:

if (a > 0)

00411ADE mov eax,dword ptr [a]
00411AE1 cmp dword ptr [eax],0
00411AE4 jle test+48h (411B08h)
if (a > 255)
00411AE6 mov eax,dword ptr [a]
00411AE9 cmp dword ptr [eax],0FFh
00411AEF jle test+3Ch (411AFCh)
b = 255;
00411AF1 mov eax,dword ptr [b]
00411AF4 mov dword ptr [eax],0FFh
else b = a;
00411AFA jmp test+46h (411B06h)
00411AFC mov eax,dword ptr [b]
00411AFF mov ecx,dword ptr [a]
00411B02 mov edx,dword ptr [ecx]
00411B04 mov dword ptr [eax],edx
else b = 0;
00411B06 jmp test+51h (411B11h)
00411B08 mov eax,dword ptr [b]
00411B0B mov dword ptr [eax],0

that's like 16 instructions! It probably takes more just to instantiate one of your matrix objects... ~Nitron.

ññòòïðïðB A
start

Kolich

same result :/

Kolich

basic time takes operation b=a. its bad.

Tim Smith

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.

Tim Smith

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.

David Chamberlain

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; if (a < 0.0f) b = 0; 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.

Antony M Kancidrowski

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.

toxcct

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 :

if (a > 0) {
if (a > 255) {
b = 255;
}
else {
b = (BYTE)a;
}
}
else {
b = 0;
}

TOXCCT >>> GEII power

toxcct

he asked for fast, not undebugable unreadable useless code ;P

TOXCCT >>> GEII power

Nitron

Actually, it's 2 _more_ instructions than the previous code. ;) I was really only kidding, I would never put that into production code... :suss: On a side note, I see you are a same-line bracer :eek: the horror! I'd much rather wade through deeply obfuscated code than to subject my tender eyes to such bracing schemes... ;P ~Nitron.

ññòòïðïðB A
start

toxcct

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

Nitron

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

toxcct

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 ! :mad:

TOXCCT >>> GEII power

Nitron

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

Toby Opferman

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

Alexander M

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! ;-)

Kolich

Most time takes b=(BYTE)a . And it is impossible to make it works faster.