Joel's Blog

Thx to my adviser I realized that there is a compiler translating the stuff that I code.  This becomes extremely relative when you are trying to time certain things.  Is the compiler really translating the code that I write to an executable that does exactly the same thing that I told it to do? Or does it think it’s better than me? :)

When I looked at Philippe’s (My adviser) java code, I realized that he had used a static variable outside the functions as the destination of the operation.  When I asked him for the reason of his decision, he answered: “If you were a compiler, and you saw a loop get executed many times to do exactly the same and the results is thrown away. What would you do?”.  I immediately realized my potential mistake and went back to the code :).  I now have two different files that I have analyzed.  One is the previous C file with some changes.  And the other is a modification of the java file that Philippe gave me [1],[2].

The following are my results when I run the commands in my machine.  I know little about what the compiler does in these cases.  With that said, the output of the commands is very…. interesting :)

The result from the C code:

[joel@jogr temp]$ gcc temp.c -O0 -o operations
[joel@jogr temp]$ ./operations 1000000000
Global variable
Add: 1890.000000 ms
Mul: 3030.000000 ms
Div: 6880.000000 ms
Local variable
Add: 2110.000000 ms
Mul: 3040.000000 ms
Div: 6900.000000 ms
[joel@jogr temp]$ gcc temp.c -O2 -o operations
[joel@jogr temp]$ ./operations 1000000000
Global variable
Add: 0.000000 ms
Mul: 540.000000 ms
Div: 4230.000000 ms
Local variable
Add: 0.000000 ms
Mul: 0.000000 ms
Div: 0.000000 ms

These results differ from the ones I posted in my first “Back of the envelope” post.  Notice that I not only changed the code to use a global var, but I also used to different compilation options.  We see here that gcc (the compiler that I used) thinks it’s really smart when used with -O2.  When it sees that I used a local variable in my for loops, it just ignored it completely.  When using a global variable it “thinks twice” about optimizing the for loop completely out and chooses something else.  Though the use of a global variable seems to be faster.

The result from the Java code:

[joel@jogr temp]$ javac C.java
[joel@jogr temp]$ java C  1000000000
Global vars:
Add: 750 ms
Mul: 1688 ms
Div: 2317 ms
Local vars
Add: 745 ms
Mul: 746 ms
Div: 744 ms
[joel@jogr temp]$

I didn’t find any optimizing option that I could use with javac, so I chose to just run it one time.  Here we see clearly that my java compiler thinks it’s really smart too.  When it sees that I’m using local variables it is faster than when I use a global variable.  This probably means that it is somehow optimizing stuff under the hood.

It is curious (to me) how much faster java is.  I confess that I don’t know lots of things that happen in the java and C compilation processes.  But I still would have thunk that, out of these two files, C would have come out on top.  I guess you never stop surprising yourself :)  That’ll teach me to pick on java :)

Would love to hear what happened when you tried it!!! Leave a comment with your results or if you see that I did something completely idiotic :)

Was reading Jon Bentley Programming Perls (second edition) [1] and  I don’t feel particularly good confessing that I had not read this book before.  It has lots of really nice programming tidbits that can be very helpful in the day-2-day.  The book is a compilation of columns that appeared in one of the ACMs publications.  Therefore it is organized in chapters that directly reflect the columns that appeared in the ACM.

I received an activity for the class that I will TA this semester.  The activity is centered in one of the chapters of Programming Perls: Back of the envelope calculations (BOEC).  In general these are quick processes that do not have to be exact and are made to make decision about a certain process.  Jon Bentley has really nice examples of situations were he has used back of the envelope calculations.  These examples are taken from real life situations that prove their importance.

The activity [2] that was given to me contains two main points: I assume that the first is intended as a warm-up activity that will lead into the second part; the second is made up of 3 curious exercises that taught me the importance of BOEC.  I basically ignored the first part and concentrated my efforts in the second section.  The first two I did in about 15 mins.  I did the calculations in my notebook and modified the values a little to make the calculations easier.  So if I had to divide by 3600, I chose to divide by 3000 (I’m lazy).  After digesting the results a little and double checking them, I continued and calculated everything with the exact values.  I used the calc command [3].  I then compared the results from my approximate calculations with the “correct” ones.  The “correct” calculations were not 100% correct as one has to assume things like average bike velocity.

What I saw when comparing the approximate value and the “correct” value was that, though they were different, their values fell into the same ball park.  That means that I would have taken the same decision based on the approximate values than on the “correct” values.  the approximate values being much faster to calculate.  In general this is a very good way to give a first tier validation to whatever you are doing.  Not happy with what I learned I coded a little script that shows exactly what I did for the first two exercises [4].

For the third exercise I just created a python script and some C code to get some numbers out.  After running them on my  box I got the following results.

For PYTHON:
1 addition in 0.00966 secs
1 subtraction in 0.00857 secs
1 division in 0.023 secs
1 multiplication in 0.0089 secs

For C: ran with argument 1000000000
1 addition in 2.62e-9
1 subtraction in 2.64r-9
1 division in 2.64e-9
1 multiplication in 2.62e-9

This is a primitive comparison of language performance.  Though this is not intended to be an accurate benchmark for integer operations, It gives us some information:  Like the fact that python will probably run 10e6 times slower than C when operating.  Or that C gets really close to an operation per cycle.  It takes a bit less than the advertised velocity for one core in my box.  And finally, python was much easier to code than C :)

I spent this week in the Conet 2010 summer school in Dagstuhl.  I beautiful place in the german mid-west.  The first days were a bit rainy, but the weather got better at the end.  This place is like the computer scientists heaven.  There is a library here with journals that date back to as far as 1958.  And they also have an archive (that I did not visit) that might hold more interesting stuff.  I found myself reading an IEEE Computer article from the early 60 that talked about how computers were starting to get too fast.  And how that increase was changing the way programmers interacted with them.  It was funny and gave me a sort of perspective.

For the first 3 days the summer school was organized in one and a half hour sessions given by well renowned professors.  On Wednesday we had some short presentations from PhD students that were describing their findings or talked about the objectives that they had for their yet to be completed projects.  Finally on Thursday and Friday we had two hands-on tutorials and additional presentations.  There are a couple of presentations on Saturday that I will unfortunately not attend.

Of the presentations I have to highlight the one that John Stancovic gave at the beginning of the summer school.  It was actually the opening presentation.  There was one thing that I noticed among the things that he touched in his presentation.  He gave a special place to the importance of robustness in cyber physical systems.  This is something that I have had in the back of my mind since I started my PhD, but it acquired a new light when it was mentioned by Prof. Stankovic.  Though it was jus t a small part of his overall presentation, it was something that I noticed and gave me a bit of direction in my work. [1]

Another highlight of the presentations was the intelligent window by Hartmut Hillmer.  His talk did not really overlap on my work on reliability on WSN, but it was witty and very expressive.  It was a breath of fresh air in a series of talks that were rapidly becoming monotonous.  His talk was centered in micromachining foundations and a window that used this technology to control sunlight use in indoor environments (among other things) [2].  I really liked it because of the way he explained concepts (used props and took various physical examples to the talk) and because he gave a wide overview of a field that I know very little about.

I also liked the talk given by Peter Cork about the work he has done throughout his career.  It gave a nice spectrum of the possibilities for WSN.  Though his talk was mainly based on robotics, most of his projects touched in some way or another on WSN. He did raise some interesting questions about some underlying assumptions that the general WSN community has had for a long time.  Mainly he questioned the overall consensus that embedded systems have very limited resources.  As I understood it, he didn’t actually want to say that embedded systems  have plentiful resource, but that in some occasions the whole thing gets  gets blown out of proportions.  And with the advent of new devices, its worth revisiting and assessing just how constraint the resources are.  This gives me hope in my search because we plan to use image recognition (notoriously resource hungry)  in embedded systems.

I met loads of people with very interesting opinions that come from all over the world and have all sorts of backgrounds.  I think this was the objective of the summer school and outweighed the presentations considerably.  First, the fact that I repeated what I was doing and what I intended to do more than a dozen times made me think about my work  and its final objective.  My peers did not notice but I was actually asking myself if what I was saying had an actual future and if it had a niche in the whole WSN community.  It was a very prolific exercise.  Though I am still far away from actually molding what I am doing into a research question, today I feel that much closer :)

I leave Dagstuhl filled with a sense of hope and new found energy.  i also regret I cannot stay a bit longer for the rest of the presentations and to bike around the region.  I went out a couple of times to explore the surroundings and found it was filled with back-roads and little cute towns.  I hope I can return in the future to Dagstuhl to another summer school or to one of its famous seminars.

[1] http://www.cs.virginia.edu/people/faculty/faculty.php?member=stankovic
[2] http://www.photonik.de/index.php?id=112&seitenid=11&fachid=762&readpdf=photonik_intl_2009_2_048.pdf&L=1