Today I attended a talk on DEVS. The presenter implemented a DEVS-RMI model for his PhD. It was early in the morning and I was tired, others were yawning too (it was a late night). The presentation didn’t focus enough on DEVS itself, it was supposed to be a tutorial on DEVS, instead it was a sales pitch for DEVS-RMI. I don’t know anything about DEVS, so it was tricky to follow although I got some interesting ideas. Some of the slides were missing labels on the axes, so it was really hard to figure out what I was looking at. From what I saw about DEVS, it looks interesting although overcomplicated. I want to look at ADEVS and CD++ to see how they implement time increments. I’d also like to benchmark YetiSim against them to see how it performs. DEVS seems to lack parallelization within its formalism, so that would be a problem. One question I had, that wasn’t answered by the presentation was whether or not the DEVS formalism can implement a Turing machine. I suppose that a Turing machine can be simulated, but it’s not quite the same. I suspect that since DEVS is based on state transitions, this is not the case. I will have to research further to understand this. The DEVS tutorial really pushed the point that the simulator could be separated from the model and system, and I took that to mean the class design and simulator.
This presentation let me see something in YetiSim I overlooked…I have no method of obtaining a signal from the outside environment without waiting for it explicitly. It just occurred to me during the discussions that I forgot to plan for this functionality. Another part of the talk that was interesting was the fact that DEVS can model both continuous and discrete systems.
Deborah and I presented YetiSim today. Unfortunately the conference did not organize the poster presentations well, so only a few people really attended it. The poster session was hosted during sessions, and the coffee for the break was in a different room. I didn’t get the audience I had hoped for, but ah well enough people were interested!
I talked with someone who had a very interesting insight, he labeled YetiSim as an “application level virtual machine”, which is a very good description of it. Although YetiSim lacks an interpreted language, in a sense it’s acting as if it is interpreting bytecode. I wonder if YetiSim could therefore do something like a JIT compiler? An interesting concept, that I could extract the code I needed, compile it, and dynamically link it in at runtime… and voila I have something that gets faster! The cost of compilation would have to be recovered however…. although I could certainly allow the user to pre-compile their execution graphs…. an interesting concept indeed…
I received a lot of feedback. The parallel performance of YetiSim was a disappointment for many, and I expressed that this is the exact reason why research is ongoing. With sufficient tools, YetiSim will improve. I already have so many new ideas for how to improve performance from peer feedback, it was really nice to have other simulation people to talk to. I definitely feel like we are going in the right direction, although I see there are things YetiSim doesn’t do yet that it really should. I’m anxious to get a new computer to continue to work on YetiSim. More people were actually interested in TBB than YetiSim though.
After the poster session, I went out with Dr. Buyya for the evening. We walked to Hull, and back to Ottawa. We also discussed GRID computing and what GRID-enabled simulation would look like. We disagree a lot on how GRID technologies should be implemented… strongly disagree actually. Dr. Buyya is a strong advocate of GRID technologies implemented in .NET, and this is the wrong approach to me. Quite simply, I do not trust any corporation which would flaunt software patent violations without merit, and threaten the industry with lawsuits. Perhaps I have a prejudiced against .NET for fear of company software patent intimidation, and hence the potential problems with the use of mono. If I were implementing GRID stuff, I would be using Python and C++. Language and platform debates will always be there, but we agreed on concepts. We went for dinner at an Indian restaurant, it was pretty good (but spicy, and I wasn’t used to it).
Posted by AJ Guillon (April 16, 2008)
