ARG Rational Software!!!!
-
Sure, but that skews the results. Makes it sort of pointless. Tim Smith "Programmers are always surrounded by complexity; we can not avoid it... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather that part of the solution." Hoare - 1980 ACM Turing Award Lecture
Tim Smith wrote: Sure, but that skews the results Perhaps I'm totally off base here, but wouldn't it 'scale' them , not 'skew' them? I'm not trying to get bogged down in semantics, really, :) I'm just saying that perhaps the information you'd get out of the test (for the inline functions and those that use them) would be a somewhat scaled representation of the execution speed of the code compiled with inlined code turned on. It wouldn't be an accurate representation of the amount of time the optimized release build would take to run, but it would give enough information to be able to optimize the inline functions themselves, wouldn't it? -- Russell Morris "Have you gone mad Frink? Put down that science pole!"
-
Tim Smith wrote: Sure, but that skews the results Perhaps I'm totally off base here, but wouldn't it 'scale' them , not 'skew' them? I'm not trying to get bogged down in semantics, really, :) I'm just saying that perhaps the information you'd get out of the test (for the inline functions and those that use them) would be a somewhat scaled representation of the execution speed of the code compiled with inlined code turned on. It wouldn't be an accurate representation of the amount of time the optimized release build would take to run, but it would give enough information to be able to optimize the inline functions themselves, wouldn't it? -- Russell Morris "Have you gone mad Frink? Put down that science pole!"
No, not at all. There is a fair amount of overhead in the actual call statement. Then if the inline routine then decides to create a stack frame, that is even more wasted time. Then when you look at the function that had the inline routine in it, when the routine isn't inlined, the optimizer can make totally different decisions based on things such as register scarcity. The same holds true for the inlined routine. The code generated for an inline routine can be DRASTICALLY different than the code generated when not inlined. Take for example two lines of code in my software. Line 1: "b += a;" This line of code took 16% of the time. Now look at this line of code: Line 2: "b += a;" This line of code took 8% of the time. ?????? But they are the same line of code, how can one take twice as long? Your guess is as good as mine since I can't see the damn MACHINE INSTRUCTIONS!!!! Also, machine instruction breakdown can give you a better idea when you have L1 or L2 cache faults. Tim Smith "Programmers are always surrounded by complexity; we can not avoid it... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather that part of the solution." Hoare - 1980 ACM Turing Award Lecture
-
No, not at all. There is a fair amount of overhead in the actual call statement. Then if the inline routine then decides to create a stack frame, that is even more wasted time. Then when you look at the function that had the inline routine in it, when the routine isn't inlined, the optimizer can make totally different decisions based on things such as register scarcity. The same holds true for the inlined routine. The code generated for an inline routine can be DRASTICALLY different than the code generated when not inlined. Take for example two lines of code in my software. Line 1: "b += a;" This line of code took 16% of the time. Now look at this line of code: Line 2: "b += a;" This line of code took 8% of the time. ?????? But they are the same line of code, how can one take twice as long? Your guess is as good as mine since I can't see the damn MACHINE INSTRUCTIONS!!!! Also, machine instruction breakdown can give you a better idea when you have L1 or L2 cache faults. Tim Smith "Programmers are always surrounded by complexity; we can not avoid it... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather that part of the solution." Hoare - 1980 ACM Turing Award Lecture
Yikes - I was way off base... :omg: Thanks for the lesson! :) -- Russell Morris "Have you gone mad Frink? Put down that science pole!"
-
Yikes - I was way off base... :omg: Thanks for the lesson! :) -- Russell Morris "Have you gone mad Frink? Put down that science pole!"
Well, it really depends on what you are after. Probably for 90% of the users, it works great. But for real high speed type work, it doesn't. Tim Smith "Programmers are always surrounded by complexity; we can not avoid it... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather that part of the solution." Hoare - 1980 ACM Turing Award Lecture
-
Now I use Rational's Pure Coverage and Purify packages and have been very happy with them. So, I decided to upgrade and include Quantify. I get the package in today and.. THE DAMN THING CAN'T SHOW YOU A LISTING BASED ON MACHINE INSTRUCTION!!! WTF? Sure, knowing that a line took 5% is great, but when that line includes an inline routine, then a FAT LOT OF GOOD THAT WILL DO YOU. My main routine that I need to test only shows three percentage values. However, the one that is taking 50% of the time is the functions "{". I can't even see if that time is from the normal function frame overhead or other stuff. WORTHLESS DAMN PACKAGE!!!! Tim Smith "Programmers are always surrounded by complexity; we can not avoid it... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather that part of the solution." Hoare - 1980 ACM Turing Award Lecture
Guess I'm glad I've never liked Rational's stuff (then again, they are starting to write competing software with my stuff in the embedded world) Not that the Numega profiler I use is anything to write home about. Tried Intel's VTune? I think they have a free trial, and it's capable of profiling all sorts of things on x86 processors. http://developer.intel.com/software/products/vtune/ Jim Wuerch www.miwasoft.com Quote from my readme files: "This is BETA software, and as such may completely destroy your computer, change the alignment of the planets and invert the structure of the universe."
-
No, not at all. There is a fair amount of overhead in the actual call statement. Then if the inline routine then decides to create a stack frame, that is even more wasted time. Then when you look at the function that had the inline routine in it, when the routine isn't inlined, the optimizer can make totally different decisions based on things such as register scarcity. The same holds true for the inlined routine. The code generated for an inline routine can be DRASTICALLY different than the code generated when not inlined. Take for example two lines of code in my software. Line 1: "b += a;" This line of code took 16% of the time. Now look at this line of code: Line 2: "b += a;" This line of code took 8% of the time. ?????? But they are the same line of code, how can one take twice as long? Your guess is as good as mine since I can't see the damn MACHINE INSTRUCTIONS!!!! Also, machine instruction breakdown can give you a better idea when you have L1 or L2 cache faults. Tim Smith "Programmers are always surrounded by complexity; we can not avoid it... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather that part of the solution." Hoare - 1980 ACM Turing Award Lecture
Tim Smith wrote: Take for example two lines of code in my software. Line 1: "b += a;" This line of code took 16% of the time. Now look at this line of code: Line 2: "b += a;" This line of code took 8% of the time. ?????? But they are the same line of code, how can one take twice as long? Dependind on B and A types, and if the += operator on both classes is doing a memory copy, this can be true. Imagine a simple string concatenation, and you'll understand what I said. Concussus surgo. When struck I rise.
-
Now I use Rational's Pure Coverage and Purify packages and have been very happy with them. So, I decided to upgrade and include Quantify. I get the package in today and.. THE DAMN THING CAN'T SHOW YOU A LISTING BASED ON MACHINE INSTRUCTION!!! WTF? Sure, knowing that a line took 5% is great, but when that line includes an inline routine, then a FAT LOT OF GOOD THAT WILL DO YOU. My main routine that I need to test only shows three percentage values. However, the one that is taking 50% of the time is the functions "{". I can't even see if that time is from the normal function frame overhead or other stuff. WORTHLESS DAMN PACKAGE!!!! Tim Smith "Programmers are always surrounded by complexity; we can not avoid it... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather that part of the solution." Hoare - 1980 ACM Turing Award Lecture
I still like the old-fashioned watches: @clk @clk = 0 for profiling code while debugging. Concussus surgo. When struck I rise.
-
No, not at all. There is a fair amount of overhead in the actual call statement. Then if the inline routine then decides to create a stack frame, that is even more wasted time. Then when you look at the function that had the inline routine in it, when the routine isn't inlined, the optimizer can make totally different decisions based on things such as register scarcity. The same holds true for the inlined routine. The code generated for an inline routine can be DRASTICALLY different than the code generated when not inlined. Take for example two lines of code in my software. Line 1: "b += a;" This line of code took 16% of the time. Now look at this line of code: Line 2: "b += a;" This line of code took 8% of the time. ?????? But they are the same line of code, how can one take twice as long? Your guess is as good as mine since I can't see the damn MACHINE INSTRUCTIONS!!!! Also, machine instruction breakdown can give you a better idea when you have L1 or L2 cache faults. Tim Smith "Programmers are always surrounded by complexity; we can not avoid it... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather that part of the solution." Hoare - 1980 ACM Turing Award Lecture
I've found that optimization is an art, not a science. In your above example, you have to consider caching of memory, instructions, and other optimizations (such as the compiler recognizing that the registers are already loaded with the memory references for b and a, so it doesn't have to load it again). To demonstrate the art of it, I've found that simply moving code around (and I'm talking about assembly source) made timing differences because of code byte alignments and caching. Yes, you absolutely need to see the assembly code. I have a dumb question--can't you use the normal debugger (I'm assuming your developing in Visual Studio), and view the assembly from the debugger? This is a lame workaround, but a workaround none-the-less??? Marc
-
Now I use Rational's Pure Coverage and Purify packages and have been very happy with them. So, I decided to upgrade and include Quantify. I get the package in today and.. THE DAMN THING CAN'T SHOW YOU A LISTING BASED ON MACHINE INSTRUCTION!!! WTF? Sure, knowing that a line took 5% is great, but when that line includes an inline routine, then a FAT LOT OF GOOD THAT WILL DO YOU. My main routine that I need to test only shows three percentage values. However, the one that is taking 50% of the time is the functions "{". I can't even see if that time is from the normal function frame overhead or other stuff. WORTHLESS DAMN PACKAGE!!!! Tim Smith "Programmers are always surrounded by complexity; we can not avoid it... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather that part of the solution." Hoare - 1980 ACM Turing Award Lecture
after three weeks of fighting with it, i finally installed BoundsChecker. now my f1 help doesn't work anymore. hooray. like you, i bought a headache. -c
Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."
-
I've found that optimization is an art, not a science. In your above example, you have to consider caching of memory, instructions, and other optimizations (such as the compiler recognizing that the registers are already loaded with the memory references for b and a, so it doesn't have to load it again). To demonstrate the art of it, I've found that simply moving code around (and I'm talking about assembly source) made timing differences because of code byte alignments and caching. Yes, you absolutely need to see the assembly code. I have a dumb question--can't you use the normal debugger (I'm assuming your developing in Visual Studio), and view the assembly from the debugger? This is a lame workaround, but a workaround none-the-less??? Marc
The problem is that the debugger doesn't tell you which instruction was taking the time. Heck, if all I wanted was to see just the instructions, I could look at the COD file. Tim Smith "Programmers are always surrounded by complexity; we can not avoid it... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather that part of the solution." Hoare - 1980 ACM Turing Award Lecture
-
Tim Smith wrote: Take for example two lines of code in my software. Line 1: "b += a;" This line of code took 16% of the time. Now look at this line of code: Line 2: "b += a;" This line of code took 8% of the time. ?????? But they are the same line of code, how can one take twice as long? Dependind on B and A types, and if the += operator on both classes is doing a memory copy, this can be true. Imagine a simple string concatenation, and you'll understand what I said. Concussus surgo. When struck I rise.
a and b are integers. It can be true for an assortment of reasons. I didn't want to go into details because it wasn't that important. My point was that it is hard to tell without seeing the actual instructions and how much time is being spent on each instruction. Tim Smith "Programmers are always surrounded by complexity; we can not avoid it... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather that part of the solution." Hoare - 1980 ACM Turing Award Lecture
-
Guess I'm glad I've never liked Rational's stuff (then again, they are starting to write competing software with my stuff in the embedded world) Not that the Numega profiler I use is anything to write home about. Tried Intel's VTune? I think they have a free trial, and it's capable of profiling all sorts of things on x86 processors. http://developer.intel.com/software/products/vtune/ Jim Wuerch www.miwasoft.com Quote from my readme files: "This is BETA software, and as such may completely destroy your computer, change the alignment of the planets and invert the structure of the universe."
I love Purify and PureCoverage. They work great. In the past I used VTune and I guess I was expecting the Rational package to be along the same lines. I am ordering my VTune upgrade Monday. Tim Smith "Programmers are always surrounded by complexity; we can not avoid it... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather that part of the solution." Hoare - 1980 ACM Turing Award Lecture
-
after three weeks of fighting with it, i finally installed BoundsChecker. now my f1 help doesn't work anymore. hooray. like you, i bought a headache. -c
Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."
I would try Purify. It might sound like I hate Rational, but actually, I LOVE Purify and PureCoverage. Tim Smith "Programmers are always surrounded by complexity; we can not avoid it... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather that part of the solution." Hoare - 1980 ACM Turing Award Lecture