I have a question: I want to time some calculations using the UNIX-time command and I figured out that Maple (I use version 16) on Ubuntu 12.04 LTS (and some other machines I tested, including Macs) has some odd properties.
calling
time maple < testCalc.txt
where testCalc.txt contains the following code:
with(DETools):
DFactor(mult(x^5*d^5 + 6*x*d +1,x^5*d^5 + x^2*d^2 +7,[d,x]),[d,x]);
results in the following output:
memory used=65.5MB, alloc=72.9MB, time=0.69
memory used=199.6MB, alloc=149.9MB, time=1.84
memory used=312.4MB, alloc=149.9MB, time=2.97
memory used=592.3MB, alloc=312.4MB, time=5.63
memory used=854.7MB, alloc=312.4MB, time=9.80
["The Result (long)"]
memory used=1132.9MB, alloc=312.4MB, time=13.06
But the additional three lines of "time" say
real 0m47.872s
user 0m0.016s
sys 0m0.000s
Clearly, the user and sys time is wrong, as maple spend 13 seconds according to its own time measurement.
It seems to me that maple uses the same sources as the time command and resets the timer every time it uses it, such that the unix-time command only captures the time since the last call of maple to this source.
This is very inconvenient, and I would like to "forbid" maple doing that. Does anyone know how to do that? Is there some flag for calling maple that lets maple not measure the timestamps on its own?
Thanks in advance for an answer.
Albert
Ugly hack coming up.
As I said in my comment, the problem is that Maple is launching a sub-process to do all of the computations. So, I created a shell script called "mserver" in my bin that looks like
#!/bin/sh
/usr/bin/time "REPLACE WITH PATH TO MSERVER ON YOUR MACHINE/mserver" $* 2> log
I then invoked Maple as
maple --kernel-binary=/Users/me/bin/mserver
At the end of a run, the file log contains the correct "time" output for the computation.
Edit: I should point out that if the Maple protocols use stderr for anything, then this will eventually cause Maple to break. I haven't seen any sign of it but I've only just played with this now.
Related
I have Pari/GP 32-bit and would like to implement any type of code which runs for a limited amount of time, then automatically stops if nothing is produced by that time. Here is a pseudocode example:
command
...
run command
if run time over 3 minutes
automatically interrupt the program and stop running
I know there is a basic way to do this, I just never found it in the PARI/GP guide. Any help? Thanks.
alarm(5);for(i=1,10^10,continue)
I'm running into some considerable speed bottlenecks with a Python-Matplotlib-Xcode combination. I know some immediate responses will probably ask "Why are you doing python stuff in Xcode, just man up and use vim" --> I like the organizing ability and the built in version control, it makes elements of my work easier to deal with.
Getting python to run in xcode in the first place was a bit more tricky than I had hoped, but its possible. Now I have the following scenario:
A master file, 'main.py' does all the import stuff for me and sets up some universal formatting to make all the figures (for eventual inclusion in my PhD thesis) nice and uniform. Afterwards it runs a series of execfile commands to generate whichever graphics I need. Two things I can think of right off the bat:
1) at the very beginning of main.py after I import all the normal python stuff you tend to need, I call a system script which checks whether a certain filesystem is mounted. I keep all my climate model data on there since my local hard drive is too small to deal with all of it at once. Python pauses itself and waits for the system to do its thing, but once the filesystem has been found, it keeps going. Usually this only needs to happen once in the morning when I get to work, or if the VPN server kicked me off for whatever reason. (Side question, it'd be cool to know if theres a trick to automate an VPN login to reconnect as soon as it notices its not connected)
2) I'm not sure how much xcode is using on its own. running the same program from terminal is (somewhat) faster. I've tried to be memory conscience and turn off stuff I don't need while running the python/xcode combination.
Also, python launches a little window whenever I call plt.show(), this in itself takes time, I've considered just saving them as quick png files and opening them with some other viewer, although I guess that would also have to somehow take time to open up. Given how often these graphics change as I add model runs or think of nicer ways of displaying the data, it'd be nice to not waste something on the order of 15 to 30 minutes (possibly more) out of the entire day twiddling my thumbs and waiting for a window to pop up.
Benchmark it!
import datetime
start = datetime.datetime.now()
# your plotting code
td = datetime.datetime.now() - start
print td.total_seconds() # requires python version >= 2.7
Run it in xcode and from the command line, see what the difference is.
This question already has an answer here:
How to abort a running program in MATLAB?
(1 answer)
Closed 7 years ago.
I write a long running script in Matlab, e.g.
tic;
d = rand(5000);
[a,b,c] = svd(d);
toc;
It seems running forever. Becasue I press F5 in the editor window. So I cannot press C-Break to stop in the Matlab console.
I just want to know how to stop the script. I am current use Task Manager to kill Matlab, which is really silly.
Thanks.
Matlab help says this-
For M-files that run a long time, or that call built-ins or MEX-files that run a long time, Ctrl+C does not always effectively stop execution. Typically, this happens on Microsoft Windows platforms rather than UNIX[1] platforms. If you experience this problem, you can help MATLAB break execution by including a drawnow, pause, or getframe function in your M-file, for example, within a large loop. Note that Ctrl+C might be less responsive if you started MATLAB with the -nodesktop option.
So I don't think any option exist. This happens with many matlab functions that are complex. Either we have to wait or don't use them!.
If ctrl+c doesn't respond right away because your script is too long/complex, hold it.
The break command doesn't run when matlab is executing some of its deeper scripts, and either it won't log a ctrl sequence in the buffer, or it clears the buffer just before or just after it completes those pieces of code. In either case, when matlab returns to execute more of your script, it will recognize that you are holding ctrl+c and terminate.
For longer running programs, I usually try to find a good place to provide a status update and I always accompany that with some measure of time using tic and toc. Depending on what I am doing, I might use run time, segment time, some kind of average, etc...
For really long running programs, I found this to be exceptionally useful
http://www.mathworks.com/matlabcentral/fileexchange/16649-send-text-message-to-cell-phone/content/send_text_message.m
but it looks like they have some newer functions for this too.
MATLAB doesn't respond to Ctrl-C while executing a mex implemented function such as svd. Also when MATLAB is allocating big chunk of memory it doesn't respond. A good practice is to always run your functions for small amount of data, and when all test passes run it for actual scale. When time is an issue, you would want to analyze how much time each segment of code runs as well as their rough time complexity.
Consider having multiple matlab sessions. Keep the main session window (the pretty one with all the colours, file manager, command history, workspace, editor etc.) for running stuff that you know will terminate.
Stuff that you are experimenting with, say you are messing with ode suite and you get lots of warnings: matrix singular, because you altered some parameter and didn't predict what would happen, run in a separate session:
dos('matlab -automation -r &')
You can kill that without having to restart the whole of Matlab.
One solution I adopted--for use with java code, but the concept is the same with mexFunctions, just messier--is to return a FutureValue and then loop while FutureValue.finished() or whatever returns true. The actual code executes in another thread/process. Wrapping a try,catch around that and a FutureValue.cancel() in the catch block works for me.
In the case of mex functions, you will need to return somesort of pointer (as an int) that points to a struct/object that has all the data you need (native thread handler, bool for complete etc). In the case of a built in mexFunction, your mexFunction will most likely need to call that mexFunction in the separate thread. Mex functions are just DLLs/shared objects after all.
PseudoCode
FV = mexLongProcessInAnotherThread();
try
while ~mexIsDone(FV);
java.lang.Thread.sleep(100); %pause has a memory leak
drawnow; %allow stdout/err from mex to display in command window
end
catch
mexCancel(FV);
end
Since you mentioned Task Manager, I'll guess you're using Windows. Assuming you're running your script within the editor, if you aren't opposed to quitting the editor at the same time as quitting the running program, the keyboard shortcut to end a process is:
Alt + F4
(By which I mean press the 'Alt' and 'F4' keys on your keyboard simultaneously.)
Alternatively, as mentioned in other answers,
Ctrl + C
should also work, but will not quit the editor.
if you are running your matlab on linux, you can terminate the matlab by command in linux consule.
first you should find the PID number of matlab by this code:
top
then you can use this code to kill matlab:
kill
example:
kill 58056
To add on:
you can insert a time check within a loop with intensive or possible deadlock, ie.
:
section_toc_conditionalBreakOff;
:
where within this section
if (toc > timeRequiredToBreakOff) % time conditional break off
return;
% other options may be:
% 1. display intermediate values with pause;
% 2. exit; % in some cases, extreme : kill/ quit matlab
end
Under most Unix-like systems, you can use the "time" command to execute a program and tell you how much space and time it used. Does anybody know of anything comparable for Windows?
(No, I don't particularly want to spend 6 months learning the Win32 API just for this...)
From the command line (low resolution, possibly inaccurate): echo %date% %time%
Programmatically: QueryPerformanceCounter. http://msdn.microsoft.com/en-us/library/ms644904(v=vs.85).aspx
If you want something of the order of millisecond accuracy (which is comparable to what the linux/unix time would give you) then timeGetTime() is what you need. It returns the number of milliseconds since the system was booted. include mmsystem.h and link against winmm.lib. However, all this would just give you a time value, you'd either need to put in a system() call in between or do something like dump the start time out to a file when called for the first time, and then read it the second time.
More pragmatic solutions, which may be more useful depending on your circumstances:
Write a batch script to call the program you wish you benchmark and wrap it so that it writes to a file:
echo "start" >> log.txt
do_my_stuff.exe
echo "stop" >> log.txt
and then use a tool as the excellent LogExpert to look at the timestamps
Install the cygwin tools and use the time that comes with that. If you only need to do this on your own machine, and the benchmark program doesn't require complex setting up (command line parameters, environment variables, etc) then this may be the easiest approach.
I use the 'time' utility in windows too. It comes with mingw+msys.
I have a Perl script that runs via a system() command from C. On a specific site (SunOS 5.10), when that script is run, it nearly always takes 6 seconds or more. On other sites, it runs pretty much instantly (0.1s). If I run the script manually, i.e. not from the C code, it also runs instantly. I eventually tracked the slowness down (by spitting out the time a whole bunch in a lot of different places), to a single require line. The file that it is requiring is another Perl script we wrote. The script consists of a single require (this file here), 3 scalars that are assigned integer values, and a handful of time/date conversion routines. The file ends with a 1;. That single require appears to take as much as 6 seconds on occasion, but as I said, not always even on the same machine. I'm absolutely stumped here. My only last thought is to turn on profiling, but the site doesn't have Devel::Profiler and my only other option (that I know of) would be to add it to the Perl command which would require me altering and recompiling the C code (doable but non-trivial).
Anybody have ANY idea what could be going on here? I don't think I can/want to put the entire date.pl that is being required, but it's pretty much exactly as I described; I could answer any questions about it that you have.
Thanks in advance.
You might be interested in A Timely Start by Jean-Louis Leroy. He had a similar problem and tracked it down to a long and deep module search path where perl usually found the modules in the last entries in #INC.
Six seconds is a long time. Have you checked what your network is doing during this?
My first thought was that spawning the new process when using the system() command could be the problem, but six seconds is too long.
I don't know much about perl, but I could imagine that for any reason, the access of the time module could invoke a call to a network time server. Just to get synchronized. Maybe this takes so long or maybe it is getting a time out.
It could be that this only happens for a newly spawned process -- hence only when you use the system() command.
just wild guessing...
So, this does nothing to answer your question directly, but please tell me that you're not actually running on perl 4? Assuming you're on perl 5, you could remove the entire file and replace the require with use POSIX qw(ctime) to get the version that comes with Perl.
If you do have to support perl4, I'll merely grumble something about version 5 being fifteen years old now and go away. :)