a b a b testGlenn, I'm supposed to send weekly progress reports. I think you already know most of this, but here it goes: I got SESC running on your machines. I downloaded ODE and compiled it for i686 architecture successfully. I was unable to test, however, because I can't seem to get X tunneling to work. I am right now trying to cross-compile ODE for MIPS, as this is what SESC requires. There are problems with the configure script. I e-mailed the ODE mailing list, but haven't received a reply. Tom and I decided the next thing to try is commenting out the regions with that crash the script (they don't seem to be critical). Tom and I talked about the direction of the project as a whole. We are hopeful that SESC will not have to be hacked extensively and the 'actual project' can start quite soon. - NathanHello Team, I had two projects to do this week. The first was to get pthreads working under SESC, and the second was to get ODE running in SESC. The pthread part was really quite simple, although I don't know if it will translate as well to more sophisticated examples. The sesc function calls do not have matching signatures to the pthread ones. All that is required to get them to work in sesc is a conversion of the functions, and then compiling 'sesc_thread.o' along with your source file. I have a makefile set up for this. The ODE part was slightly more challenging, but after navigating through the makefile it wasn't too awful. ODE tries to compile a *.so as the final result. This won't work for sesc, so what I did was remove that step from the dependency chain. Instead, I take all the intermediary object files and compile them along with the source (there's probably a way to combine them into a single file, but I hadn't thought of that until just now). It takes a while to compile, and the executable is pretty big, but it works, and that's what matters. I have one test running using the ODE engine. I have it spit out a random statistic each frame (the angle on one joint), and it matches the x86 version perfectly. If it isn't running correctly, then that's a pretty amazing coincidence. I have one question, though. I'm having trouble capturing output from sesc. This sounds crazy, but using standard redirect ">" doesn't work for the sesc emulator. The normal output doesn't appear, but it doesn't go into the redirected file either. I don't know what the issue is, but if you guys know please shout it out. That's all, - NathanI looked at how to convert pthread to SESC API calls, and realized that it was more complicated than originally thought. Talked with Tom about how to proceed, and we are looking at some new source code from the developer of SESC. Might be able to get away with a less-functional conversion. - NathanThis week I... i. ...wrote a test case to spawn two threads with unbalanced workloads to test thread affinity in the SESC simulator. Wrote another test that caused the simulator hang for as-yet undetermined reasons (but Tom seems to know why). ii. ...investigated the core library files for SESC and got a much better understanding of how the simulator works, particularly in how it captures system calls and executes them itself. This might be useful for later when we add in our own quirks to the simulator. iii. ...thought really hard about physics acceleration, but couldn't come up with any amazing ideas. I had a few bad ones, though, such as starting the next frame while the previous one is still going. Who knows, maybe it is genius and I just don't realize it. - NathanGents, This week I accomplished: testing overhead of spawning threads and synchronizing them. The overhead appears to be minimal. I was then going to start on some libnet stuff to help Paul (or just learn it myself), but my CS 133 project is proving to be a real pain the neck and I didn't get to that yet. As far as I know, Tom is still working on converting the pthread to SESC synchronization calls. This week I had the brilliant idea of seeing if theres a particular operation that occurs in ODE that we could create a custom instruction for that would speed up things significantly. Then Tom said it was a stupid idea because any application can be sped up this way, so we'd have to have something very convincing to justify it. I also thought about how the cores / caches could be laid out in the grid, but I realized that this isn't so much an idea as a bunch of questions I need to ask you. - Nathan This week was basically my final's week. I had a final paper due, a presentation for a class project, the checkpoint slides, and another class project, as well as the usual homework. I did not have time to contribute to the research. I do plan, however, on spending a good chunk of time during Spring break looking over Paul's side of things and hopefully making good progress on integrating libnet with SESC. - NathanGents, This week was a busy one because I had rush for my fraternity. Over the weekend I put some hours in on the research and got most of the SESC-ification of ODE finished. One large problem remains, however. The main part of my task was building a pthread_cond_t equivalent using the SESC threading and synchronization API. After doing some reading on the pthread specification, I implemented this using SESC locks and suspending/waking threads when they were signaled. Unfortunately, it appears that the suspension/waking of threads is not properly functioning. Previously we had tested barriers and other API calls, and I guess that this part of the API was somehow neglected. I then went through the ODE code and replaced all remaining pthread calls with SESC equivalents. I have e-mailed the maintainer of SESC with my question about the API, and I hope to get a reply during the day tomorrow and fix it tomorrow night, which means that if all goes well, SESC-ification will be complete by our next weekly meeting. As for what I came up with that was new this week, we all discussed in our weekly meeting what parts of the project Paul and I would take over once the infrastructure is up. Because the thesis is due in May, depending on how well the infrastructure goes (particularly the libnet side of things), we might have to focus on improvements and refinements of prior work rather than an entirely new direction for the research. - Nathan Beckmann Professor Glenn, Here's my progress for the week: After much investigation delving into the internals of SESC, I have isolated the problem with suspend and resume of threads. Tom suggested a remedy for the problem that should solve our problems; it should be fairly simple to implement. I thought of one idea for a back-up project if SESC continues to have problems; we are going to talk about this tomorrow, I assume. - Nathan BeckmannHello, This week I confirmed that the fix for the suspension bug works. It also appears that my implementation of condition variables works. I am currently hung up on a compiler error message when compiling ODE, so I can't test it in SESC. This week we finalized the new direction for the project, which I have e-mailed you about separately. Each part of this problem seems simple so I am optimistic that it will be done by the thesis deadline. Unfortunately, over the next week I have some kind of test or essay in all of my other classes so I will be busy. I will make sure I keep making progress. - NathanWhat I accomplished: We have some initial results for running tests with a few different cache configurations. I realized that some of the parameters might need to change to make the tests completely fair. New idea: Talked with Glenn a lot about the motivation and prior work for the cache study. Started thinking about my hyptothesis for the results of the tests (see Thesis draft), and initial test results are in agreement with my hypothesis. - NathanProgress: This week was pretty quiet. After finishing the thesis draft, I had family obligations that consumed the entire weekend. I met with Glenn to discuss the final steps for this project, which are fairly simple: 1) Run tests with various test apps on each configuration. 2) Look at performance results. 3) Make some graphs, finalize thesis. We've had some infrastructure issues with getting the jobs run, but this shouldn't be a major obstacle. Working on resolving that now. As for new ideas, the final steps of this project are very straight-forward, and until the results come in there is little innovation to be done.