The car market is pretty fascinating in many ways. Going out actually buying a car quite recently, I was given cause to reflect on prize vs actual size. The non-linear prize increase you have to pay to get to a slightly bigger car from whatever point you are at is interesting. And the fact that a “very small” car is just above four meters long, while a “pretty large” car is at around five meters. How can a few centimeters actually matter that much?
Intel has a really neat tool on their homepage: the Intel ARK — Automated Relational Knowledgebase. It is a horrible name for a brilliant tool: it lets you search for processor names, codenames, chipsets, and jump around in a database of processor variants, compatible chipsets, feature lists, and more. Not that I care particularly about Intel chips, but the tool is something everyone selling silicon devices should copy. Being able to quickly figure out just what is inside a certain device (and what is not), and finding related devices and compatible chips is just brilliant for curious people, customers, and supporting services.
Please, everybody else?
Just like in 2006, I went to the Øredev conference in Malmö and presented a workshop using Virtutech Simics. This year, I worked with Jonas Svennebring from Freescale and we created a workshop around parallelizing network processing software for running on a multicore Freescale processor. The workshop went reasonably well, and the participants definitely learned something about what we trying to get across, even though we did not have much time to actualy complete the programming assignments.
I just found out that my favorite Windows XP PowerToy is built into Windows Vista. To get to a command-prompt located in any folder directly from the Explorer, follow the instructions found at a Microsoft MSDN blog: Tim Sneath : Windows Vista Secret #1: Open Command Prompt Here. Very useful. But why not make it more obvious than “press shift while right-clicking?”.
A small tidbit that I found interesting due to the targeted platform. LinuxDevices reports that the VirtualLogix VLX-NI virtualization layer that used to run only on x86 platforms now also run on TI DSPs in the C64+ series. Basically, you put their virtualization layer on the DSP, and you can then on the same core run both a Linux kernel and a DSP/BIOS kernel. Thus supporting traditional DSP development and Linux-style development on the same core.
An old colleague just sent me an email bringing up a discussion we had last year, where he was a strong proponent for the homogeneous model of a multiprocessor. The root of that discussion was the difference between the Xbox 360 and Playstation 3 processors. The Xbox 360 has a three-core, two-threads-per-core homogeneous PowerPC main processor called the Xenon (plus a graphics processor, obviously), while the PS3 has a Cell processor with a single two-threaded PowerPC core and seven SPEs, Synergistic Processing Elements (basically DSP-like SIMD machines).
In the game business, it is clear that the Xenon CPU is considered easier to code for. This means that even though the Cell processor clearly has higher theoretical raw performance, in practical the two machines are about equal in power since it is harder to make use of the Cell. Which seems to be a fact.
So here, homogeneous systems do appear to have it easier among programmers. However, I do not believe that that extends to all systems, all the time, everywhere.
Game engine development company Valve has a nice presentation up on their website about how they attacked multithreading. It is a nice example of how to solve multicore programming for a particular domain by the classic layered approach.
I just got a funny error message from YouTube. Searching for quite innocuous terms like “Ã…nglok” a highly trained group of Monkeys kept popping up. Read on for screen dump.
The TimeSys Embedded Linux Podcast (also called LinuxLink Radio) is a nice listen about embedded computing using Linux. Sometimes they are a bit too open-source centric, though, and ignore very good tools that live in the classic commercial world. One such example is the recent episode 20 on debugging tools, where they totally ignore modern high-powered hardware-based debugging.
In a report from FTF Paris 2007, Info World makes some interesting comments on security and locking-down of mobile devices. Info World Â» Blog Archive Â» â€˜Flat IPâ€™ mobile networks face new security challenges:
The new version of Trango’s embedded “secure virtualizer” for the ARM Cortex-A9 MPCore is an interesting solution in that it directly applies virtualization technology to the issue of migrating solutions (complete software stacks) from single-core to multicore. The details are a bit sketchy in just how this is done, there is some hardware support in recent ARM architectures, but a little bit of adaptation of a guest OS using paravirtual techniques are likely not a blocker. It also touches on security, implemented using ARM’s trustzone technology. All in all, I think this is a typical example of something that we are going to see much more of.
One common use-case for multicore processing on the desktop and elsewhere is “doing many things at the same time”. You could be running many user-interface programs at once, like the “typical today’s teenager template” of tens of IM clients, web sessions, email conversations, music and video players, downloading movies, etc. Or it is a more business-like background indexing of harddrives, backups being taken, downloading large business files, compiling software, updating source code repositories, etc.
I have been doing both of these modes to some extent, and the main problem with them at least on a PC is that while the processors might be good at multitasking and sharing the CPU load, my IO system is annoyingly non-parallel.
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.
Continue reading “Golf Games and Computer Simulations”
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.
A question that pops up quite often when computer architects and representatives from firms like Intel encounter a crowd today is but just what do you need more computing power for????. Most regular users are fairly happy with the speed at which they process words, surf the web, read email, do IP phone calls, crunch numbers in Excel, and other common tasks. It is hard to perceive the need for more speed in everyday tasks, unlike a decade or two ago when you could definitely ask for improvement. I remember scrolling a page in PageMaker on a Mac SE (8Mhz 68000). You counted the clicks and waited for the screen to jump, redraw, jump, redraw, stabilize… quite a different experience from working with modern computers and far more complex software that still responds instantaneously to almost any work.
The “Handbook of Real-Time and Embedded Systems” (ToC, Amazon, CRC Press) is now out. I and my university research colleague and friend Andreas Ermedahl have written a chapter on worst-case execution time analysis. We talk some about the theories and techniques, but we try to discuss practical experience in actual industrial use. Both static, dynamic, and hybrid techniques are covered.
I just got my personal copy, but my first impression of the book overall is very positive. The contents seems quite practical to a large extent, not as academic as one might have feared. Do check it out if you are into the field. It is not a collection of research paper, rather instructive chapters informed by solid research but with applications in mind.
A short update to the previous posting on how to compress video for the nano.
It turns out that the “iPod video” profile of Nero Recode is half aimed at showing video from your iPod on external devices. That’s the only good reason for the “high” resolution. I typically got a video size of 15MB per minute with these settings, which quickly fills up even gigabytes of space.
Using the “iPod Video-AVC” profile instead is optimized for viewing on the Nano itself and not on some external device. The resolution is down to 320×200-240 depending on source aspect ratio. And the resulting files are only about 5MB per minute, much more manageable for carrying a large video library on an iPod. I cannot see any difference in the quality of the output…
Update (2007-September-23): The default iPod-AVC setting has some issue with rapid cross-fades between scenes. To get around this, I set the quality settings to “2-pass” and “highest quality” in the detailed settings you can make in the second screen before moving on to actually encode things. This created very nice looking video that had no problems handling even the previously broken fades.
The cost was even more compute time. I think the current settings takes some 5 to 10 hours per material hour to encode (on my Athlon XP 2700+, not exactly a screamer by current standards).
This is not in my self-assigned range of topics, but I like when other people put up their helpful notes of how to accomplish some task that I am researching. Thus, I feel obliged to do the same when I have tested something reasonably new.
The task at hand here is “how to get video into an iPod Nano”.
It just dawned on me recently (and it sure must have been obvious to those working with configuring AMP — Assymtric Multiprocessing Systems) that in an AMP setup, the operating systems involved actually know about each other and have to account for the fact that they are sharing a single processor chip with other operating systems. So you cannot just take two single-core operating system images from an existing multiple-processor (local memory) solution and put them on a single chip and things just work. You do need to prepare the boot process and find a way to nicely share the common I/O devices, timers, accelerator engines and other resources on the chip. This is materially different from a virtualized setup.
Some more thoughts on how to program multicore machines that did not make it into my original posting from last week. Some of this was discussed at the multicore day, and others I have been thinking about for some time now.
One of the best ways to handle any hard problem is to make it “somebody else’s problem“. In computer science this is also known as abstraction, and it is a very useful principle for designing more productive programming languages and environments. Basically, the idea I am after is to let a programmer focus on the problem at hand, leaving somebody else to fill in the details and map the problem solution onto the execution substrate.
Back in 1996, DVP celebrated its 15th anniversary. When looking through my digital and paper archive, I found this gem: The official badge and logo for the 1996 anniversary! We also produced some mouse pads with this logo on them, one of which I still use for my daily job. Pretty good quality I must say.
The picture shown here was saved as GIF for use on the web. But scarily enough, apart from a few more GIF files, I could not open or even understand the file type of most of the files from that time, only ten years ago. Our digital archives are not very robust — more on that below.
The SICS Multicore Day August 31 was a really great event! We had some fantastic speakers presenting the latest industry research view on multicores and how to program them. Marc Tremblay did the first presentation in Europe of Sun’s upcoming Rock processor. Tim Mattson from Intel tried hard to provoke the crowd, and Vijay Saraswat of IBM presented their X10 language. Erik Hagersten from Uppsala University provided a short scene-setting talk about how multicore is becoming the norm.
A company called Fastscale Technologies has a product that is simple in concept and yet very powerful. Instead of using complete installs of heavy operating systems like Linux or Windows to run applications on virtual machines, they offer tools that provide minimal operating system configurations that are tailored to the needs of a particular application. Since only that application is going to be run on the virtual machine, this is sufficient. According to press reports, this means that you can run several times more virtual machines on a given host, compared to default OS installs. And boot an order of a magnitude faster.
Just found a man with the same name as me also blogging: http://jakobengblom.blogspot.com/. Funny. But I know there are few people with my name in Sweden, so it is not that much surprising.
ArsTechnica is running a history of the Amiga, and in part 3, “The first prototype” they describe a really interesting “simulation” solution for the custom chips in the first Amiga. This is in 1982-83, and there are no VHDL or Verilog simulators, nor any other EDA tools as we know them today. Even if they were, the Amiga company would not have been able to afford them. So in order to test their design, the Amiga engineers built chip replicas using breadboards and discrete logic chips. All in all, 7200 chips and a very large numbers of wires. Quite fascinating stuff, and they did manage to interface the main 68000 CPU to the breadboards and get a fully functional if a bit slow simulation of a complete Amiga computer with all its unique custom chips.
My dear old education program, DVL, later DVP, (which made us call it DV*) is celebrating its 25th anniversary with a large dinner at Norrlands Nation on October 6, 2007. The official site is www.dvp.nu/25. I really hope that I can make it, it would be great seeing all of the other alumni frÃ¥n datavetenskapliga linjen/programmet and see where they have ended up and what they are doing now.
They also emailed out a call for pictures from the history of DV*. I’ll look through my old collections of memorabilia and see what I can find. What a chance for a trip down memory lane. It’s been ten years since I graduated. Time flies.
Sun slots transactional memory into Rock | The Register
That is just so cool! For us around Stockholm, we can hear Marc Tremblay talk about this at the SiCS Multicore Day on August 31, 2007.