I wanted to try and figure out why bitmap locking is so dreadfully slow in OpenGL on my laptop but I can't build the profiling version of allegro due to undefined references to mcount.
I believe both the source modules and the library need to be linked with -pg for this to work correctly. I don't know where to look in the cmake files to fix this though. Any ideas?
]]>
There is a Profile build type. Did you try it?
]]>Sorry, yes. I should have mentioned the cmake parameters I used :
Yeah, I also tried it without the monolith and it fails the same way.
Edit
I looked through CMakeLists.txt and I found this :
It sets a flag for the source modules and for the linker so I'm not sure what is wrong. Perhaps the library needs a separate linker parameter in cmake?
]]>There is a separate linker flag for shared libs iirc.
]]>From
http://www.cmake.org/pipermail/cmake/2011-December/048040.html
On 12/12/2011 09:00 PM, Robert Dailey wrote:
I need a version of CMAKE_EXE_LINKER_FLAGS for shared libraries. I need
to specify /NODEFAULTLIB for a shared library (DLL) that I'm building,
but it doesn't seem that CMAKE_EXE_LINKER_FLAGS is used by shared
library projects generated by CMake for visual studio.
Any suggestions?
Use CMAKE_SHARED_LINKER_FLAGS. Strangely, this family of variables is
missing from the docs...
Michael
So we need to use CMAKE_SHARED_LINKER_FLAGS somewhere? Like in the profiling section above? cmake confuses me.
]]>Pretty much yeah.
]]>so we need to use CMAKE_SHARED_LINKER_FLAGS somewhere? Like in the profiling section above? cmake confuses me.
You should use CMAKE_SHARED_LINKER_FLAGS instead of CMAKE_EXE_LINKER_FLAGS.
Try to use the CMAKE_VERBOSE_MAKEFILE option so we see the actual link command passed to the command line (warning: LOTS of text).
]]>You could just pass: VERBOSE=1 to make. if you want to see the commands make runs.
]]>I think it does just the same....but I'll try it out
]]>You should use CMAKE_SHARED_LINKER_FLAGS instead of CMAKE_EXE_LINKER_FLAGS.
I would assume we still need CMAKE_EXE_LINKER_FLAGS though, as the examples and demos would all need to be linked with -pg.
I got it to build by changing the above section from CMakeLists.txt to the below :
I kept CMAKE_EXE_LINKER_FLAGS_PROFILE and added CMAKE_SHARED_LINKER_FLAGS_PROFILE as -pg and added it to the mark_as_advanced section below (I have no idea what that does).
Everything seems to build fine, all the demo, examples and library worked fine. When run, the exe's produce gmon.out like they're supposed to but gprof is giving me some messed up results, and doesn't even include the allegro functions in the profile, which I can't explain. I'm trying to upgrade my compiler as we speak, prob won't finish til tomorrow though.
Yeah, the output from gprof is not making any sense at all. For example, I ran ex_threads and then ran gprof on it :
Only log_printf is listed in the flat profile, and none of the allegro functions even show up!
]]>You are using WinXP, right? There are some other profiler options but they tend to be Vista+.
]]>Do all the files contain debugging symbols? I am unsure the profile flags include '-g'
EDIT: well okay that should not matter at all.
]]>My laptop is Vista, my desktop is XP. I do my dev work on my laptop. What other profilers are you talking about SiegeLord?
Allegro builds successfully, and both the source modules and the library are now linked with -pg, but gprof doesn't show any allegro functions in the flat profile. I don't get it, this used to work with allegro 4? What gives?
Edit
Submitted a patch to AD.
Anyone have any suggestions on what to replace gprof with? Or why gprof no longer works? I've read things that suggest gprof doesn't work with shared libraries but like I said this used to work with Allegro 4.
]]>Were the libraries also compiled with -pg?
]]>Yes, that's what the CMAKE_SHARED_LINKER_FLAGS_PROFILE patch was for. And the output from gprof is still useless. It says there were 6 calls to main, which is ridiculous and obviously wrong.
So, anyone know any good profiling tools for Windows?
]]>LINKER_FLAGS aren't for compiling. lib source has to be compiled with -pg as well
]]>Yup. It's there already. The flag I mentioned was for building the library, and fixed the issue with unresolved references to mcount.
set(CMAKE_C_FLAGS_PROFILE "-pg" CACHE STRING "profiling flags")
]]>
I tried compiling Allegro with profiling (i.e. -pg) but none of the examples ran after that treatment, so I'm not sure what is up.
As for other profilers, I just tried Very Sleepy profiler and it picked up Allegro functions (note that I had to compile with -gdwarf-2 to get it to recognize the debug symbols. Perhaps the same will help your profile build?).
]]>I tried VerySleepy last night, and when I tried to attach to a process or launch a new one it just quit, and the program didn't run either.
Support for GCC/mingw. You can now profile executables with embedded DWARF2 data and it should work. No special options are required for this, just compile with “-g” to make sure you have symbols present. You may also wish to use “-fno-omit-frame-pointer” to ensure correct callstacks, although Sleepy will generally work either way. You don’t need to use “-pg” or any rubbish. It can even walk correct stacks between a Microsoft DLL into a GCC one, which was harder than you’d think.
I tried to profile a simple test program with these directions, using -g and -fno-omit-frame-pointer and every time I try to launch the program from verysleepy the program crashes and VerySleepy quits. My test program doesn't crash when run by itself though. The last release of VerySleepy was in November 2011 so I don't have high hopes for a fix unless I figure out what is wrong by myself, but that is another whole project in itself which I don't really want to get into.
I would try CodeXL but that is Win7+.
I couldn't get VerySleepy to work with -gdwarf-2 either. :/
]]>I've succeded in building gperftools in MSYS2...I'll try to play around with the CPU profiler on your example Bitmaplocking.cpp rebuilding it in 32bits exe with all the deps statically linked in.
I don't know if I'm doing something useful but trying should not hurt, I guess.
gperftools on windows have been ported only to a minimal libTmalloc, no sight of the CPU profiler
]]>YAPTDWOW. (Yet another profiler that doesn't work on windows)
That's disappointing. I'm beginning to think it would be better to profile opengl on Linux and try to improve it's functioning there in the hopes of improving it on Windows too. :/
]]>I'm beginning to think it would be better to profile opengl on Linux and try to improve it's functioning there in the hopes of improving it on Windows too. :/
I have the same impression, but me personally can only unse a VM and I doubt that could help a lot.
Nevertheless, the cumulative call stack could help....I discovered only now that I should have compiled with '-f-no-omit-frame-pointer' ...
]]>