GPROF flat profile empty result - gcc

I'm trying to use gprof (I have to use gprof - no other option is available) when I get the flat file the result is empty even though everything works fine.
By the way, the code is in c so I'm using gcc.
Result:
Each sample counts as 0.01 seconds.
no time accumulated
% cumulative self self total
time seconds seconds calls Ts/call Ts/call name
What can I do to fix this? Thank you.

You can use gcc -no-pie option as a workaround.

Related

Defining TOC & SDA in GNU-PPC Linker Script

Im using the GCC Compiler for Tricore and PPC since a while.
On the PPC side, i didn't figured out until now, how i can define TOC & SDA addresses for the compiler to use to shorten the code.
Im adding code into some existing binary, which is using TOC 0x5C9FF0 (%R12) and SDA 0x7FFFF0 (%R13).
If im writing my code in the linker script it works perfectly fine if i am writing it in asm directly like this, to access an variable via SDA:
But in "normal" code like this:
It will load "epc_blink_timer", which is defined #0x806F10 (in reach of SDA), it will access it via an lis/lhz combination. This takes a lot of space, which i don't have, and also unnecessary CPU usage:
Is there any way to define TOC/SDA, or at least SDA somewhere in my linker files, and tell the compiler to use them?
I literally tried it since years, but don't had luck so far.
Br. Chris

Very Sleepy doesn't see function names when capturing MinGW compiled file

I am new to this so probably missing something basic.
I compile my C program with gcc 4.8 (MinGW) and -g option.
I then run it and capture it with Very Sleepy. It all works but the output of Sleepy looks like this:
memcpy 0.98 0.98 7.65 7.65 msvcrt unknown 0
[00000000004038FE] 0.77 0.77 6.02 6.02 a 0
memset 0.63 0.63 4.92 4.93 msvcrt unknown 0
[0000000000404549] 0.42 0.42 3.29 3.29 a 0
[000000000040282A] 0.35 0.35 2.73 2.73 a 0
[0000000000404600] 0.25 0.25 1.99 1.99 a 0
....
etc.
(my application is called a.exe)
So Sleepy doesn't see function names, how do I need to compile/run to make it work ?
Sleepy website gives:
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.
But it's not enough in my case.
Usually we call the very sleepy command (or any other debugging tool) with the arguments:
-O0: sets default code optimization (more optimized code used to reduce time or space can hide some functions)
-g: it's used to retain the name of the functions and the variable, that are mangled by default in order to optimize the executable, but it makes it less debuggable: gcc -g :what will happen
-fno-omit-frame-pointer : it's also used to improve debugging by ommiting frame pointers (a feature used to improve performance but that makes the debug less readable), according to When should I omit the frame pointer?. With that option, the output assembly code is more simple. That helps the debugger
-gdwarf-2: https://gcc.gnu.org/onlinedocs/gcc-3.4.5/gcc/Debugging-Options.html specifies that it's set to force the output debugging format to "dwarf2". In fact, the -g option just tells the compiler to "retain some information". gdwarf will specify the output format (if possible).
You can also add a -glevel to indicate the precision of the output information. The default one is 2. It does not retain macros and some definitions. Maybe you can set it to 3.
If it's not enough maybe you can give a minimal working sample to see the exact problem (which function should appear in the log)?
I hope it will help

Luaj os.time() return milliseconds

os.time() in Luaj returns time in milliseconds, but according to lua documentation, it should return time in seconds.
Is this a bug in Luaj?
And Can you suggest a workaround that will work with Luaj(for java) and real Lua(c/c++)? because i have to use the same lua source for both applications.(cant simply divide it with 1000, as they both have return different time scale)
example in my lua file:
local start = os.time()
while(true) do
print(os.time() - start)
end
in c++ , i received output:
1
1
1
...(1 seconds passed)
2
2
2
in java (using Luaj), i got:
1
...(terminate in eclipse as fast as my finger can)
659
659
659
659
fyi, i try this on windows
Yes there's a bug in luaj.
The implementation just returns System.currentTimeMillis() when you call os.time(). It should really return something like (long)(System.currentTimeMillis()/1000.)
It's also worth pointing out that the os.date and os.time handling in luaj is almost completely missing. I would recommend that you assume that they've not been implemented yet.
Lua manual about os.time():
The returned value is a number, whose meaning depends on your system. In POSIX, Windows, and some other systems, this number counts the number of seconds since some given start time (the "epoch"). In other systems, the meaning is not specified, and the number returned by time can be used only as an argument to os.date and os.difftime.
So, any Lua implementation could freely change the meaning of os.time() value.
It appears like you've already confirmed that it's a bug in LuaJ; as for the workaround you can replace os.time() with your own version:
if (runningunderluaj) then
local ostime = os.time
os.time = function(...) return ostime(...)/1000 end
end
where runningunderluaj can check for some global variable that is only set under luaj. If that's not available, you can probably come up with your own check by comparing the results from calls to os.clock and os.time that measure time difference:
local s = os.clock()
local t = os.time()
while true do
if os.clock()-s > 0.1 then break end
end
-- (at least) 100ms has passed
local runningunderluaj = os.time() - t > 1
Note: It's possible that os.clock() is "broken" as well. I don't have access to luaj to test this...
In luaj-3.0-beta2, this has been fixed to return time in seconds.
This was a bug in all versions of luaj up to and including luaj-3.0-beta1.

Is there a way to speed up the library loading in R?

I have a Rscript that will load ggplot2 in its first line.
Though loading a library doesn't take much time, as this script may be executed in command line for millions of times so the speed is really important for me.
Is there a way to speed up this loading process?
Don't restart -- keep a persistent R session and just issue requests to it. Something like Rserve can provide this, and for example FastRWeb uses it very well -- with millsecond round-trips for chart generation.
As an addition to #MikeDunlavey's answer:
Actually, both library and require check whether the package is already loaded.
Here are some timings with microbenchmark I get:
> microbenchmark (`!` (exists ("qplot")),
`!` (existsFunction ('qplot')),
require ('ggplot2'),
library ('ggplot2'),
"package:ggplot2" %in% search ())
## results reordered with descending median:
Unit: microseconds
expr min lq median uq max
3 library("ggplot2") 259.720 262.8700 266.3405 271.7285 448.749
1 !existsFunction("qplot") 79.501 81.8770 83.7870 89.2965 114.182
5 require("ggplot2") 12.556 14.3755 15.5125 16.1325 33.526
4 "package:ggplot2" %in% search() 4.315 5.3225 6.0010 6.5475 9.201
2 !exists("qplot") 3.370 4.4250 5.0300 6.2375 12.165
For comparison, loading for the first time:
> system.time (library (ggplot2))
User System verstrichen
0.284 0.016 0.300
(these are seconds!)
In the end, as long as the factor 3 = 10 μs between require and "package:ggplot2" %in% search() isn't needed, I'd go with require, otherwise witht the %in% search ().
What Dirk said, plus you can use the exists function to conditionally load a library, as in
if ( ! exists( "some.function.defined.in.the.library" )){
library( the.library )
}
So if you put that in the script you can run the script more than once in the same R session.

Timing a Fortran multithreaded program

I have a Fortran 90 program calling a multi threaded routine. I would like to time this program from the calling routine. If I use cpu_time(), I end up getting the cpu_time for all the threads (8 in my case) added together and not the actual time it takes for the program to run. The etime() routine seems to do the same. Any idea on how I can time this program (without using a stopwatch)?
Try omp_get_wtime(); see http://gcc.gnu.org/onlinedocs/libgomp/omp_005fget_005fwtime.html for the signature.
If this is a one-off thing, then I agree with larsmans, that using gprof or some other profiling is probably the way to go; but I also agree that it is very handy to have coarser timers in your code for timing different phases of the computation. The best timing information you have is the stuff you actually use, and it's hard to beat stuff that's output every single tiem you run your code.
Jeremia Wilcock pointing out omp_get_wtime() is very useful; it's standards compliant so should work on any OpenMP compiler - but it only has second resolution, which may or may not be enough, depending on what you're doing. Edited; the above was completely wrong.
Fortran90 defines system_clock() which can also be used on any standards-compliant compiler; the standard doesn't specify a time resolution, but gfortran it seems to be milliseconds and ifort seems to be microseconds. I usually use it in something like this:
subroutine tick(t)
integer, intent(OUT) :: t
call system_clock(t)
end subroutine tick
! returns time in seconds from now to time described by t
real function tock(t)
integer, intent(in) :: t
integer :: now, clock_rate
call system_clock(now,clock_rate)
tock = real(now - t)/real(clock_rate)
end function tock
And using them:
call tick(calc)
! do big calculation
calctime = tock(calc)
print *,'Timing summary'
print *,'Calc: ', calctime

Resources