|
Chesnokov Yuriy wrote: Those are neither present ...
Strange, I can see them in all those places. Are you sure they are in the block that you have stopped at, and also that you are running the Debug version of your project?
It's time for a new signature.
|
|
|
|
|
I always use debug version.
I stepped line by line after those variables declared and they are not visible
Чесноков
|
|
|
|
|
Chesnokov Yuriy wrote: I always use debug version.
I thought so, but still had to ask.
Chesnokov Yuriy wrote: I stepped line by line after those variables declared and they are not visible
As I said, I put those lines in a small test program and all were visible.
I can only assume something has gone wrong with one or more of the files containing the debug information. Try rebuilding the project and see if that changes anything.
It's time for a new signature.
|
|
|
|
|
Have you created your own project and used IPP face detection main code or used original solution?
I do not want to create solution from scratch and add all those files and code.
Чесноков
|
|
|
|
|
Chesnokov Yuriy wrote: Have you created your own project and used IPP face detection main code or used original solution?
Neither, I just pasted your code into a simple program to make sure I could see the variables in the debugger.
Chesnokov Yuriy wrote: I do not want to create solution from scratch and add all those files and code.
I'm not sure what this has to do with your problem. I merely suggested running a complete rebuild of your project to ensure all the compiler and linker debug information was up to date.
It's time for a new signature.
|
|
|
|
|
For sure if I put the same variables to the clean program it will work.
I cleaned it and rebuilt without profit.
Only after I moved them to the point where main() function starts execution (as with C style declare them all first) debugger started to see them.
Once I move them back to their original place they are invisible again!
Чесноков
|
|
|
|
|
Chesnokov Yuriy wrote: Only after I moved them to the point where main() function starts execution (as with C style declare them all first) debugger started to see them.
Once I move them back to their original place they are invisible again!
This does not make sense, can you show the code for both instances, and where you stop in the debugger when they can or cannot be seen?
It's time for a new signature.
|
|
|
|
|
That will be hard to investigate, you need to install http://registrationcenter.intel.com/irc_nas/1749/w_ipp-samples_p_6.1.5.060.zip[^] along with IPP and Intel compiler.
The console application is face detection one. It is too big to fit and you will not be able to debug it without all those tools installed.
When you get to the variables from my question post and step over them you will not be able to see them.
Чесноков
|
|
|
|
|
Well, I guess the problem lies elsewhere within this sample code, so unless you can find someone else who has tried it out you are at an impasse. Sorry I cannot offer any other ideas.
It's time for a new signature.
|
|
|
|
|
Have you turned the optimiser off? Compilers are quite good at creating code that's equivalent to your source with a lot of the redundant stuff you've put in for readability removed.
Cheers,
Ash
|
|
|
|
|
That is debug build from IPP project. There is No Whole Program Optimization and in Linker->Optimization all fields are cleared.
Чесноков
|
|
|
|
|
As Aescleal hinted at...
You will get this sort of thing in Release. There's not those variables to display, as the code is heavily optimised. You want to check this sort of thing in Debug first.
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
It is debug build. I can not see permanently only those variables but all stepping over the lines is normal.
In release even stepping in debugger is wierd.
Чесноков
|
|
|
|
|
configuration of your solution is "Debug"?
|
|
|
|
|
|
These are the debug build command lines
/I"..\..\image-codecs\ijg\include" /I"samples" /I"C:\Program Files (x86)\Intel\Compiler\11.0\ipp\ia32\include" /Zi /nologo /W0 /WX- /Od /Oy- /D "_DEBUG" /D "WIN32" /D "_WIN32" /D "_WIN32_WINNT=0x500" /D "_WINDOWS" /D "STRICT" /D "_MBCS" /D "_CRT_SECURE_NO_DEPRECATE" /D "_CONSOLE" /Gm- /EHsc /RTC1 /MTd /Zp16 /GS /fp:precise /Zc:wchar_t /Zc:forScope /openmp- /Fp"_bin/Win32/Debug/Face_Detection_obj\Face_Detection.pch" /Fa"_bin/Win32/Debug/Face_Detection_obj\" /Fo"_bin/Win32/Debug/Face_Detection_obj\" /Fd"_bin/Win32/Debug/Face_Detection_obj\vc100.pdb" /Gd /analyze- /errorReport:queue
/OUT:"_bin/Win32/Debug\Face_Detection.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"..\..\image-codecs\ijg\_bin\Win32\Debug" /LIBPATH:"C:\Program Files (x86)\Intel\Compiler\11.0\ipp\ia32\stublib" "ippcc.lib" "ippi.lib" "ipps.lib" "ippcore.lib" "ippcv.lib" "ippj.lib" "ijg6b.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "uuid.lib" "comctl32.lib" "Ws2_32.lib" "winmm.lib" "wininet.lib" "vfw32.lib" "winspool.lib" "ole32.lib" "oleaut32.lib" "odbc32.lib" "odbccp32.lib" /MANIFEST /ManifestFile:"_bin/Win32/Debug/Face_Detection_obj\Face_Detection.exe.intermediate.manifest" /ALLOWISOLATION /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\DATA\Program Files\Intel\ipp-samples\image-processing\Face_Detection\_bin\Win32\Debug\Face_Detection.pdb" /SUBSYSTEM:CONSOLE /OPT:NOREF /PGD:"C:\DATA\Program Files\Intel\ipp-samples\image-processing\Face_Detection\_bin\Win32\Debug\Face_Detection.pgd" /TLBID:1 /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:QUEUE
Чесноков
|
|
|
|
|
Having a real-time app which main processing function is invoked as much as 20-30fps performing some image processing is it better to preallocate all temporary buffers used or it does not cost to invoke allocations?
E.g. having to build pyramid of images with specific rescaling for 640x480 image might not consume much of the memory using preallocation scenario.
On the contrary for 15Mpx image the pyramid preallocation is very costly in consuming OS memory.
Is there a frequent memory allocation cost in real-time apps performance?
I remember I tested it long time before and each ::new operation took about dozen of millisecs or so while malloc() was 0 ms.
Чесноков
|
|
|
|
|
Chesnokov Yuriy wrote: I remember I tested it long time before and each ::new operation took about dozen of millisecs or so while malloc() was 0 ms.
new does not simply allocate memory, it will also call the object constructor.
I'd suggest using some kind of memory pool, pre-allocating your data structure and swap data in/out.
Watched code never compiles.
|
|
|
|
|
Try profiling it and see - that's the only way you're ever going to know for sure. Presumably you're talking about a soft real time application like a game rather than a hard real time app - if you're talking hard real time then I'd suggest getting a real time OS before doing anything else.
Cheers,
Ash
|
|
|
|
|
I would try and reuse those buffers, i.e. allocate the required number of them and keep using them over and over again. That is the cheapest way of them all, as it does not cost any CPU cycles, and it does not cause excessive cache trashing. It does put the responsibility in your hands though, you must make sure to use the buffers consistently.
|
|
|
|
|
Don't forget: "Early optimization is the root of all evils"... Well, I prefer to weaken this famous sentence by replacing "all" with "many", but anyway: The advice given above might pay off, but for different reason independent of using new or malloc:
If you allocate and release on free store with high frequency, (possibly in a long running application) you almost certainly run into fragmentation issues making allocations increasingly slow or impossible... As mentioned above new invokes constructors and some mechanics regarding correct behaviour in case of exceptions. You should not give this up - In our team, I do not accept c++ code which contains other free store queries than new and delete
|
|
|
|
|
"In our team, I do not accept c++ code which contains other free store queries than new and delete" ...
For a Windows application? No wonder the memory gets fragmented.
What about HeapCreate/HeapAlloc/HeapFree for larger custom data objects?
VirtualAlloc/VirtualFree for large data objects? The fastest one there - evrything else just layers on top of VirtualAlloc.
|
|
|
|
|
The Gdiplus Bitmap:Save method returns void and generates two exceptions, ArgumentNullException and ExternalException, neither of which cover the case where a save fails because, say, there is not enough space on the disc or trying to write to a read-only disc. Can anyone tell me how to detect such a failure. My program seems to silently ignore such failures. Thanks for any help.
Niklas Lindquist's suggestion of calling GetLastError solves the problem. After a little experimentation I discovered that Bitmap::Save set the last error to 0 if it succeeds so if GetlastError((0 returns a non-zero value there has been an I/O error. Thanks for the two replies.
-- Modified Tuesday, August 24, 2010 2:33 PM
|
|
|
|
|
One idea could be to check if GetLastError() changes.
(and please don't cross post[^])
|
|
|
|
|
Thanks for your reply which has helped me to solve my problem. I found that Bitmap::Save sets the last error to 0 if (it thinks) it is successful and non-zero if it fails.
Sorry about the cross-post. This is my first attempt at using the bulletin board and I thought that my first post had failed.
Thanks again for your help.
Hugh McIntyre.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
