Herb Sutter about C++, great keynote.
I still receive a lot of hits for my earlier post about how to export Excel charts to PDF in order to include them in a LaTeX document. Various keywords also indicate that a lot of people want to kind of automate that process and export many charts at once. Luckily that is also possible now. I have not checked for the PC version yet (if you do it would be great if you could tell me in the comments or view some other channel but here is how-to for Microsoft Excel 2011 for the Mac:
1. Create your charts (that step should be obvious)
3. Select “Save as Picture” from the context menu
4. Check the Box “Save each graphic as a separate file” and select format PDF:
5. Enter a name. Note: The name entered here will result in Excel: a) creating a directory with the name b) saving each selected diagram with name “<entered-name>-<number>.pdf”. So for example “Charts”:
with the two earlier selected charts will result in:
6. All selected charts will be saved and automatically cropped, ready to be included in your document.
7. This works similarly in Microsoft Word and Microsoft Powerpoint.
Plan for a sabbatical (yeah, before actually starting a job I make plans for a sabbatical :
Wohoo.. my thesis project is coming together, today I got the first output that actually provided information about the benchmarked application. Great accomplishment even though it’s just a simple hybrid (OpenMP, MPI) jacobi:
[lwm2] lwm2-analysis.c:11 -------------------------------------------------- [lwm2] lwm2-analysis.c:12 Run successfully completed [lwm2] lwm2-analysis.c:21 Wallclock time: 6.34 s [lwm2] lwm2-analysis.c:28 -------------------------------------------------- [lwm2] lwm2-analysis-mpi.c:25 MPI analysis: [lwm2] lwm2-analysis-mpi.c:54 General event count for Event MPI_Allreduce: 3 Time: 1308671560.8108737469 Avg Time: 436223853.6036245823 [lwm2] lwm2-analysis-mpi.c:54 General event count for Event MPI_Bcast: 2 Time: 0.0001499653 Avg Time: 0.0000749826 [lwm2] lwm2-analysis-mpi.c:54 General event count for Event MPI_Comm_rank: 2 Time: 0.0000009537 Avg Time: 0.0000004768 [lwm2] lwm2-analysis-mpi.c:54 General event count for Event MPI_Comm_size: 2 Time: 0.0000009537 Avg Time: 0.0000004768 [lwm2] lwm2-analysis-mpi.c:54 General event count for Event MPI_Irecv: 2 Time: 0.0000290871 Avg Time: 0.0000145435 [lwm2] lwm2-analysis-mpi.c:54 General event count for Event MPI_Isend: 2 Time: 0.0000259876 Avg Time: 0.0000129938 [lwm2] lwm2-analysis-mpi.c:54 General event count for Event MPI_Reduce: 2 Time: 0.0001509190 Avg Time: 0.0000754595 [lwm2] lwm2-analysis-mpi.c:54 General event count for Event MPI_Type_commit: 2 Time: 0.0000061989 Avg Time: 0.0000030994 [lwm2] lwm2-analysis-mpi.c:54 General event count for Event MPI_Type_create_struct: 2 Time: 0.0000038147 Avg Time: 0.0000019073 [lwm2] lwm2-analysis-mpi.c:54 General event count for Event MPI_Waitall: 32 Time: 39260146779.9131774902 Avg Time: 1226879586.87228679 [lwm2] lwm2-analysis-omp.c:42 Program has spent 68.43 % of the overall time in OpenMP parallel regions [Omp Events: 362 General Events: 529]
In general my thesis project is a “light-weight monitoring module” (short: lwm2) that is automatically attached to all jobs running on a high-performance computing cluster and collects various metrics. These are then shown to the user after the application has finished. Due to the light-weight nature – running applications should be influenced as little as possible – only certain metrics can be collected. Therefore the module is of course not able to provide deep insight into the application but certain (potential) problems will be detected and these results shall act as a starting point for further analysis using more sophisticated tools. Examples for these tools might be Scalasca, Vampir, ThreadSpotter, or other tools our of the HOPSA package (lwm2 is also a, albeit small, part of the HOPSA project).
Open questions which will be (hopefully) answered in the thesis are
- which metrics can be collected without compile-time instrumentation. For example, while there does exist a profiling interface MPI, OpenMP has no support for tools apart from some vendor specific tools.
- which problems with parallel (and, of course, also serial) programs can be detected with an overhead of not more than 1% of the application’s wall-clock time
- how to rank and present these problems to a user in such a way that they know what to do next
- how to make sure, that the module – despite pulling various tricks to gain insight into monitored programs without compile-time instrumentation – is as robust as possible and does not introduce bugs or instabilities into the monitores programs
At the moment I’m using the excellent Pomodoro application on my Mac for tracking all my pomodoros during the day. While it already supports changing your Adium/Skype status to DND with a custom message during a pomodoro I also wanted to suppress Outlook “new mail” notifications.
Fortunately Pomodoro supports executing AppleScript scripts for certain events so I used the following snippets to enable/disable these Outlook notifications:
Disable on start/resume:
tell application "Microsoft Outlook" set display alerts to false set play sound on new message to false end tell
Enable on end/reset:
tell application "Microsoft Outlook" set display alerts to true set play sound on new message to true end tell
It’s working great so far.
As we all know data is everything in optimizing and improving web pages. Until last week Impera lacked the functionality to display data over time. Even though we were able to show some snapshots of certain metrics (in German):
there was no continuous tracking and measuring enabled. On Friday I finally wrote some background scripts which save certain metrics at fixed time intervals. These can then be displayed using the amazing jQuery flot graph library as beautifully formatted graphs over time. Here you can see the average number of online players per hour (GMT+1 timezone and mostly German users from GMT+1):
I think the results are as expected with a peak during the day and a valley after 2 a.m. However, this data is only aggregated over a timespan of two and a half days. I expect the following graph to be more of interest when a few weeks of data have been captured:
Even with this little data it can be inferred, that Impera players get up earlier on Mondays than on weekends (what a surprise!).
There are a few other graphs available but more data is needed for them to be of any interest.
I am currently developing a new in-game interface for www.imperaonline.de, and from time to time I will display a sneak peak here: