Frank Schirrmeister of Synopsys recently published a blog post called “Busting Virtual Platform Myths – Part 1: “Virtual Platforms are for application software only”. In it, he is refuting a claim by Eve that virtual platforms are for application-level software-development only, basically claiming that they are mostly for driver and OS development and citing some Synopsys-Virtio Innovator examples of such uses. In his view, most appication-software is being developed using host-compiled techniques. I want to add to this refutal by adding that application-software is surely a very important — and large — use case for virtual platforms.
Tag Archives: Software Tools
It is a week ago now, and sometimes it is good to let impressions sink in and get processed a bit before writing about an event like the SiCS Multicore Days. Overall, the event was serious fun, and I found the speakers very insightful and the panel discussion and audience questions added even more information.
In the July 2008 issue of IEEE Computer, there is short article called “In Praise of Scripting: Real Programming Pragmatism“, by Ronald P. Loui, a professor at Washington University (WUSTL). The article deals with the issue of what is the appropriate first language to teach new CS (Computer Science) students, and considers that a “scripting” langauge like Python or Ruby might be way better than Java (no doubt about that I think).
What can this teach us for the purpose of simulation and the creation of models of computer system hardware for the purpose of simulation? Maybe a fair bit…
I just spent the first week of Summer vacation practising the Swedish national sport of home renovation. It seems that everyone is doing that all the time nowadays – it might be that I have reached the age of family raising where that becomes important, or it might be that it is a general trend that more people spend more time and money renovating their homes. I think it is the second case.
Anyhow, what we set out to do this year was to replace (most of) the twenty-year-old wooden decking on the backside of our small row house with a new one. This was quite an adventure, as we discovered all kinds of interesting designs and problems with the old decking structure. Problems, which do reflect on the realities of computer programming and simulation.
Yesterday, I had the honor of being the opponent at the PhD defense of Simon Kågström at Blekinge Tekniska Högskola (BTH, Blekinge University of Technology in English). His PhD thesis deals mainly with the multiprocessor port of an industrial in-house operating system, and a secondary theme was the design of the Cibyl C-programs-to-JVM translator. All of his papers are very well-written and a joy to read, and the engineering work behind it is very solid.
The most important data in the PhD thesis is really just how much work it is to do an SMP port of an OS kernel. And how hard it is to get performance up to good levels even with several years of work. Really emphasizes the point that hard work and perseverance and just lots of calendar time is what it takes to create a good SMP OS. That’s why Solaris and AIX are still years ahead of Linux in this respect — you just need to hit the snags, fix them, retest, and hit the next snag. It takes time to polish, basically.
So, if you have any interest in multiprocessor operating systems, Simon’s work is well-worth a read. Also check out his blog at http://simonkagstrom.livejournal.com/. And by the way, he did pass.
The Register has a pretty good report from the Supercomputing (SC) 2007 conference. Quite knowledgeable, and mostly about the thorny issue of programming massively parallel fairly homogeneous machines likes GPUs and floating-point accelerators. Of course, their commentary has to be commented on. Read on for more.
I just read a EETimes report from a panel at the Power.org Developers Conference (actually, it is more accurately called the Power Architecture Developers Conference, of PADC), about programming multicore processors for the embedded market. Note that I was not there in person, so I can only take the few quotes in the article and comment on them. The main conclusions are that:
- C/C++ is going to be the dominant language for embedded for the near future. Nothing really surprising at that.
- C/C++ being dominant means that parallelism in multicore processors, especially shared-memory systems, will be harder to exploit. That is certainly true.
- Tool vendors have no good idea about what to do next.
- You cannot expect to get traction with a new language.
In a sense, blaming the market for not having the good sense to adapt new tools to tackle multicore.
I don’t think things have to be that bleak.
In my work at Virtutech trying to explain Simics and its simulation philosophy, it is often a struggle to get people to accept that what seems like pretty brutal simplifications of the world actually work quite nicely. Recently, I found a nice analogy in a golf game/simulator. The type where you swing a real club and send a real golf ball through the air.
Read More →
Joel Spolsky is always worth a read, and in his post Strategy Letter VI he has a lot of smart things to say about how to consider programming. His basic message is that if you optimize your code too much to work well and fit in the memory of a current machine, by the time that you are done, you find yourself run over by competitors that just assumed machines would be faster and used the same programming time to implement cooler products.
I just have to take issue with this.