MeeGo combines Intel’s Moblin and Nokia’s Maemo projects at the Linux Foundation to create one open source uber-platform for the next generation of computing devices: tablets, pocketable computers, netbooks, automotive IVI and more.

says the Foundation’s Jim Zemlin.

Watching the joint Intel and Nokia interview it seemed to me that this is more Maemo than Moblin, especially since Nokia’s Qt framework and Qt Creator IDE is mentioned as the primary application development platform for MeeGo.

The most significant factor is that Intel and Nokia will now be backing the same mobile OS. You would expect this to have an impact, though I guess the move is an attempt to win back mindshare that has gone to Android, the up and coming mobile OS from Google.

Although both Android and MeeGo are based on Linux, the Android OS has a completely different development model based on Java rather than C/C++.

Related posts:

1. Hands on with Intel Moblin
2. Nokia acquires Trolltech,
3. Nokia announces N900, juggles three operating systems

Intel secretly redesigned key software, known as a compiler, in a way that deliberately stunted the performance of competitors’ CPU chips.

A few days ago Agner Fog wrote an article that sheds some light on the subject:

The reason is that the compiler or library can make multiple versions of a piece of code, each optimized for a certain processor and instruction set, for example SSE2, SSE3, etc. The system includes a function that detects which type of CPU it is running on and chooses the optimal code path for that CPU. This is called a CPU dispatcher. However, the Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string. If the vendor string says “GenuineIntel” then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version.

Fog also notes a clause in Intel’s November 2009 settlement with AMD [PDF] in which the company undertakes not to:

include any Artificial Performance Impairment in any Intel product, or require any Third Party to include an Artificial Performance Impairment … “Artificial Performance Impairment” means an affirmative engineering or design action by Intel (but not a failure to act) that (i) degrades the performance or operation of a Specified AMD product (ii) is not a consequence of an Intel Product Benefit and (iii) is made intentionally to degrade the performance or operation of a Specified AMD product.

It is a fine distinction. At what point does failure to optimise constitute “affirmative engineering”? What riles developers is that even when an non-Intel CPU reports support for an optimisation such as SSE, the Intel-compiled code will not use it unless it is an Intel CPU. You could argue that this is an inaction (failure to optimise) rather than an action (deliberately running slower); but the end result is the same, worse performance on non-Intel processors.

The obvious practical solution is to use other compilers, but for certain types of work Intel’s compiler is considered the best.

Has Intel now agreed to do a better job? You tell me; I don’t think the clause quoted above tells us one way or another. I do think it is legitimate for the government to press Intel at least to take advantage of obvious optimisations on third-party processors, since this benefits everyone. Even so, Intel will always optimise best for its own CPUs and that is to be expected.

Performance tests are another issue. It is deceptive to produce test results showing performance differences without also revealing that in one case the code is optimised, and in another it is not. That said, if Intel has a smart optimisation that is specific to its own CPUs, there is no reason why it should not trumpet the fact. This is a matter of disclosure.

Finally, developers take note: if you are compiling for a general market that might or might not be using Intel CPUs, maybe the Intel compiler is not the best choice.

Related posts:

1. US Federal Trade Commission sues Intel
2. Bloor on the failure of antivirus products
3. The desktop versus web application debate

the FTC alleges that Intel has waged a systematic campaign to shut out rivals’ competing microchips by cutting off their access to the marketplace. In the process, Intel deprived consumers of choice and innovation in the microchips that comprise the computers’ central processing unit, or CPU.

The FTC’s main complaint is that Intel allegedly used:

threats and rewards aimed at the world’s largest computer manufacturers, including Dell, Hewlett-Packard, and IBM, to coerce them not to buy rival computer CPU chips. Intel also used this practice, known as exclusive or restrictive dealing, to prevent computer makers from marketing any machines with non-Intel computer chips.

There is also a complaint about GPUs, though it’s not yet clear to me whether this is because the FTC considers that bundling a GPU with the motherboard or CPU sale is anti-competitive in itself, or some other issue.

The FTC also makes what to me is an intriguing complaint about Intel’s compiler:

In addition, allegedly, Intel secretly redesigned key software, known as a compiler, in a way that deliberately stunted the performance of competitors’ CPU chips. Intel told its customers and the public that software performed better on Intel CPUs than on competitors’ CPUs, but the company deceived them by failing to disclose that these differences were due largely or entirely to Intel’s compiler design.

I am struggling a bit with this one. Is the FTC saying that Intel’s compiler has code in it that says in effect:

if (!IntelCompiler) { GoSlowly(); }

Or is the FTC merely saying that the Intel compiler optimises for Intel hardware – which is not a a secret; I’ve been told this by Intel on many occasions.

Clearly if customers were deceived by this in demonstrations the FTC has a point; but the kind of customer who is interested in CPU performance tests is likely to be familiar with the idea that compilers can optimise for specific hardware. It’s a good thing too; if I have Intel hardware I want a compiler that will optimise for features specific to that hardware.

Intel has issued the following statement:

“Intel has competed fairly and lawfully. Its actions have benefited consumers. The highly competitive microprocessor industry, of which Intel is a key part, has kept innovation robust and prices declining at a faster rate than any other industry. The FTC’s case is misguided. It is based largely on claims that the FTC added at the last minute and has not investigated. In addition, it is explicitly not based on existing law but is instead intended to make new rules for regulating business conduct. These new rules would harm consumers by reducing innovation and raising prices.”

Intel senior vice president and general counsel Doug Melamed added, “This case could have, and should have, been settled. Settlement talks had progressed very far but stalled when the FTC insisted on unprecedented remedies – including the restrictions on lawful price competition and enforcement of intellectual property rights set forth in the complaint — that would make it impossible for Intel to conduct business.”

“The FTC’s rush to file this case will cost taxpayers tens of millions of dollars to litigate issues that the FTC has not fully investigated. It is the normal practice of antitrust enforcement agencies to investigate the facts before filing suit. The Commission did not do that in this case,” said Melamed

Related posts:

1. How Intel’s compiler underperforms on other CPUs: artificial impairment versus failure to optimise
2. Intel gets into the App Store game – but where does Silverlight fit in?
3. Intel: don’t bother us with bug reports

Moblin (it rhymes with Goblin) is aimed at netbooks running Intel’s Atom processor, though it also runs on other Intel processors – mine is a Core 2 Duo. The supplied intro says it is a “completely new user experience” and “the next evolution in operating systems”. Well, one thing greatly impressed me. Moblin booted perfectly when plugged into my Toshiba M400 Portege laptop, playing sound and video, and picking up the wi-fi card without any messing around.

Next, I spent a few minutes exploring the user interface. There are some fun, bouncy mouse-over effects, though the cutesy default imagery, featuring an unlikely friendship between what I think is a cat and some birds, did nothing for me. I discovered a browser based on Mozilla, but hiding many of its features, a media player, an application gallery with easy install of a selection of further apps (the usual Linux things), and an effort to bring social networking to the fore by integrating with Twitter and last.fm, with others presumably to follow.

I am not sure about it though; I suspect the first thing I would do with a Moblin netbook is to work out how to install Ubuntu or some other Linux that is less sugar-coated and exposes all the features I am used to; and I suspect most users (given the choice) would rather have Windows 7.

My instant and probably unfair reaction is that Microsoft has nothing to fear from Moblin, even though I can see that a lot of work has gone into making it easy to use.

It is an interesting contrast to Google Chrome OS, which I have also been trying. Although Moblin has more features right now, Chrome OS is more compelling; Chrome OS feels stripped-down rather than simplified, and embraces a new model of computing that I think can be made to work.

Incidentally, Google acknowledges Moblin as one of the open-source projects which it uses in Chrome OS.

Related posts:

1. Nokia Maemo, Intel Moblin gives way to MeeGo
2. Microsoft brings Silverlight – not Mono – to Linux via Intel
3. Intel gets into the App Store game – but where does Silverlight fit in?

In order to participate as a developer, you have to sign up for the program, which will cost $99 annually though currently it is free. An interesting twist is that the developer program is a component market as well as an application market. Write a cool component, and you can get paid whenever any application that uses your component is sold. Intel handles all the business details, for a cut of course.

Intel is supporting two operating systems, Windows and Moblin, Intel’s Linux distribution. Your applications must be one of the following:

• Native Windows (I am not sure whether .NET is allowed)
• Native Moblin
• Java
• Adobe AIR

A puzzle is that Intel’s press release makes several references to Silverlight as a cross-platform runtime; yet although there is a Linux version of Silverlight, called Moonlight, there isn’t any exact equivalent to AIR for desktop Silverlight and I am not clear how Silverlight fits in any of the categories above. I may be reading too much into this; but perhaps all will be explained when Silverlight 4 is unveiled at PDC in November? Here’s what the press release says:

“Using Silverlight’s cross-device, cross-browser, cross-platform technology, developers will be able to write applications once and have them run on Windows and Moblin devices – expanding the reach of Silverlight applications to more consumers, regardless of whether the device they’re using is a PC, TV or phone,” said Ian Ellison Taylor, general manager, Microsoft Client Platforms and Tools.

Note that despite the above quote, Moonlight 2.0 is still in beta, and no current phones include the Silverlight runtime.

Apps must be delivered in one of the following forms:

• .msi (for Windows*)
• .jar (for Java*)
• .air (for Adobe® AIR*)
• .deb (for Debian Mobilin/Linux)
• .rpm (for RedHat* Linux)

All applications in the store are subject to Intel’s approval (called validation):

The validation process checks your code for suitability for the Developer Program, licensing and legal issues, and some basic functionality.

Here’s the checklist. Note this requirement:

Runtimes and technologies the application can support can only be any of the following: Moblin* Native, Windows* Native, Adobe AIR*, Java FX *, and Microsoft* Silverlight*.

Hmm, Silverlight again.

Intel gets 30% of your revenue. You can also market components and if your application uses a paid-for component a share of the revenue will be paid to the component vendor. Free applications and components are also permitted.

I really like the checklist – I wish all desktop applications conformed to some of the requirements. Like this one:

The application will completely uninstall when desired, and leave no garbage files behind.

are great to read.

You can sign up here, though the SDK is not yet available.

One curious facet of the program is that although it is specifically for the Atom, in most cases your application will likely run fine on other processors. I am not sure if Intel will do anything to ensure that only Atom-powered computers use the store.

In May I posted that we should get ready for more app stores. This is really coming to pass now, with Adobe’s offering which I mentioned yesterday, Nokia’s Ovi, as well as others for Android, Palm Pre and so on.

Related posts:

1. Microsoft brings Silverlight – not Mono – to Linux via Intel
2. Hands on with Intel Moblin
3. Nokia Maemo, Intel Moblin gives way to MeeGo

My own upgrade went better than the last one, but I’ve still had problems. Specifically:

• I had to edit Grub’s menu.lst manually after the upgrade. I always have to do this, since it detects the hard drive configuration incorrectly.
• My Adobe AIR installation was broken and had to be re-installed
• I’ve lost hardware graphics acceleration and desktop effects. This is a laptop with embedded Intel graphics; apparently this is a common problem and Intel graphics support in Jaunty is work in progress. See here for more details an experimental suggested fix, which is not for the faint-hearted.

There are other updates, of course, and I was glad to see Mono 2.0.1 and MonoDevelop 2.0 available in the repository, for .NET development on Linux. If Jaunty is the same as before, but faster and more stable, that is no bad thing, though the shaky Intel graphics support undermines that argument.

My question: why is Canonical persevering with its policy of supposedly major releases every six months? This looks to me like a minor update; would it not be better presented as updates to 8.10, and focusing efforts on 9.10 in October? Six-monthly releases must be a heavy burden for the team.

I don’t mean to put you off Ubuntu. It is well worth trying either as a companion or alternative to Windows and Mac.

Update:

I have fixed my desktop effects. How? First, a little more about the problem. DRI (Direct Rendering Infrastructure) was not enabled. My graphics card (from lspci –nn | grep VGA) is:

Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)

The problem I had before was reported in Xorg.0.log as:

Xorg.0.log:(EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI.

I also noticed that /dev/dri/card0 did not exist on my system.

Well, I tried the technique described here. That is, I booted into an older version of the kernel; the oldest available on my system being 2.6.22.14. DRI magically started working. Then I rebooted into the latest version of the kernel, 2.6.28.11. DRI still works. So I am sorted. I’d be interested to know why this works.

Related posts:

1. Ubuntu Desktop not used in business
2. Ubuntu Linux: the agony and the ecstasy
3. What to say about Ubuntu Hardy Heron?

It is a little confusing. Mostly Parallel Studio replaces the earlier products for Windows developers using Visual Studio; though we were told that there are some advanced features in products like VTune that meant you might want to stick with them, or use both.

Intel’s fundamental point is that there is no point in having multi-core PCs if the applications we run are unable to take advantage of them. Put another way, you can get remarkable performance gains by converting appropriate routines to use multiple threads, ideally as many threads as there are cores.

James Reinders, Intel’s Chief Evangelist for software products, introduced the products and explained their rationale. He is always worth listening to, and did a good job of summarising the free lunch is over argument, and explaining Intel’s solution.

That said, there are a few caveats. Here are five reasons why adding parallelism to your code might not be a good idea:

1. Is it a problem worth solving? Users only care about performance improvements that they notice. If you have a financial analysis application that takes a while to number-crunch its data, then going parallel is a big win. If your application is a classic database forms client, it is probably a waste of time from a performance perspective. You care much more about how well your database server is exploiting multiple threads on the server, because that is likely to be the bottleneck.

There is a another reason to do background processing, and that is in order to keep the user interface responsive. This matters a lot to users. Intel said little about this aspect; Reinders told me it is categorised as convenience parallelism. Nevertheless, it is something you probably should be doing, but requires a different approach than parallelising for performance.

2. Will it actually speed up your app? There is an overhead in multi-threading, as you now have to manage the threads as well as performing your calculations. The worst case, according to Reinders, is a dual-core machine, where you have all the overhead but only one additional core. If the day comes when we routinely have, say, 64 cores on our desktop or laptop, then the benefit becomes overwhelming.

3. Is it actually desirable on a multi-tasking operating system? Consider this: an ideally parallelised application, from a performance perspective, is one that uses 100% CPU across all cores until it completes its task. That’s great if it is the only application you are running, but what if you started four of these guys (same or different applications) simultaneously on a quad-core system? Now each application is contending with others, there’s no longer a performance benefit, and most likely the whole system is going to slow down. There is no perfect solution here: sometimes you want an application to go all-out and grab whatever CPU it needs to get the job done as quickly as possible, while sometimes you would prefer it to run with lower priority because there are other things you care about more, such as a responsive operating system, other applications you want to use, or energy efficiency.

This is where something like Microsoft’s concurrency runtime (which Intel will support) could provide a solution. We want concurrent applications to talk to the operating system and to one another, to optimize overall use of resources. This is more promising than simply maxing out on concurrency in every individual application.

4. Will your code still run correctly? Edward Lee argues in a well-known paper, The Problem with Threads, that multi-threading is too dangerous for widespread use:

Many technologists are pushing for increased use of multithreading in software in order to take advantage of the predicted increases in parallelism in computer architectures. In this paper, I argue that this is not a good idea. Although threads seem to be a small step from sequential computation, in fact, they represent a huge step. They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism. Threads, as a model of computation, are wildly nondeterministic, and the job of the programmer becomes one of pruning that nondeterminism. Although many research techniques improve the model by offering more effective pruning, I argue that this is approaching the problem backwards. Rather than pruning nondeterminism, we should build from essentially deterministic, composable components. Nondeterminism should be explicitly and judiciously introduced where needed, rather than removed where not needed.

I put this point to Reinders at the conference. He gave me a rather long answer, saying that it is partly a matter of using the right libraries and tools (Parallel Studio, naturally), and partly a matter of waiting for something better:

Law articulates the dangers of threading. Did we magically fix it or do we really know what we’re doing in inflicting this on the masses? It really come down to determinism. If programmers make their program non-deterministic, getting out of that mess is something most programmers can’t do, and if they can it’s horrendously expensive.

He’s right, if we stayed with Windows threads and Pthreads and programming at that level, we’re headed for disaster. What you need to see is tools and programming templates that avoid that. The evil thing is what we call shared mutable state. When you have things happening in parallel, the safest thing you can do is that they’re totally independent. This is one of the reasons that parallelism on servers works so well, in that you do lots and lots of transactions and they don’t bump into each other, or they only interface through the database.

Once we start opening up shared mutable state, encouraging threading, we set ourselves up for disaster. Parallel Inspector can help you figure out what disasters you create and get rid of them, but ultimately the answer is that you need to encourage people to use programming like OpenMP or Threading Building Blocks. Those generally guide you away from those mistakes. You can still make them.

One of the open questions is can you come up with programming techniques that completely avoid the problem? We do have one that that we’ve just started talking about called Ct … but I think we’re at the point now where OpenMP and Threading Building Blocks have proven that you can write code with that and get good results.

Reinders went on to distinguish between three types of concurrent programming, referring to some diagrams by Microsoft’s David Callaghan. The first is explicit, unsafe parallelism, where the developer has to do it right. The second is explicit, safe parallelism. The best approach according to Reinders would be to use functional languages, but he thinks it unlikely that they will catch on in the mainstream. The third type is implicit parallelism that’s safe, where the developer does not even have to think about it. An example is the math kernel library in IPP (Intel Integrated Performance Primitives) where you just call an API that returns the right answers, and happens to use concurrency for its work.

Intel also has a project called Ct (C/C++ for Throughput) which is a dynamic runtime for data parallelism, which Reinders considers also falls into the implicit parallelism category.

It was a carefully nuanced answer, but proceed with caution.

5. Will your application need a complete rewrite? This is a big maybe. Intel’s claim is that many applications can be updated for parallelism with substantial benefits. A guy from Nero did a presentation though, and said that an attempt to parallelise one of their applications, a media transcoder, had failed because the architecture was not right, and it had to be completely redone. So I guess it depends.

This brings to mind another thing which everyone agrees is a hard challenge: how to design an application for effective parallelism. Intel has a tool in preparation called Parallel Advisor, to be part of Parallel Studio at a future date, which is meant to identify candidates for parallelism, but that will not be a complete answer.

Go parallel, or not?

None of the above refutes Intel’s essential point: that effective concurrent programming is essential to the future of computing. This is an evolutionary process though, and at this point there is every reason to be cautious rather than madly parallelising every piece of code you touch.

Additional Links

Microsoft has a handy Parallel Computing home page.

David Callaghan: Design considerations for Parallel Programming

Related posts:

1. Functional programming, NOSQL themes at QCon London
2. Visual Studio 2010 and .NET Framework 4.0 – a simply huge release
3. Adobe AIR: 10 reasons to love it, 10 reasons to hate it.

Very witty; but don’t the ad folk mind about what this image evokes – pain, broken skin, mess, hospitals?

I’ll stick to writing.

Related posts:

1. Hi, got a Dell? Outlook slow? Let me fix it
2. US Federal Trade Commission sues Intel
3. Hands on with Intel Moblin

Note that both Virtual PC and VirtualBox can use Intel’s Virtualization Technology CPU extensions (AMD have similar extensions, but I’m running on an Intel Core 2 Quad). I ran PassMark on XP Pro with SP3, under both Virtual PC and VirtualBox, with hardware virtualization first enabled, and then disabled. I ran it full screen, with as little as possible running on the underlying OS (Vista 32-bit). PC additions were installed. Both virtual machines were given 512MB RAM. Here are the surprising (to me) results:

• Virtual PC 2007 with hardware virtualization: 399.6
• Virtual PC 2007 without hardware virtualization: 345.9
• VirtualBox 1.5.6 with hardware virtualization:  542.9
• VirtualBox 1.5.6 without hardware virtualization: 616.4

So on my machine (your results may vary) VirtualBox is faster without hardware virtualization, and more than 50% faster than the best result from Virtual PC.

I drilled into the results a little. On the CPU tests there was not a big difference; in some cases Virtual PC was ahead. On the Graphics 2D tests though, VirtualBox was dramatically faster – more than twice as fast on the GUI test, for example. It was also dramatically faster on disk I/O. For example:

Disk- Sequential Read: VirtualBox 143.4 MB per second vs Virtual PC 90.8 MB per second

Disk – Sequential Write: VirtualBox 97.4 MB per second vs Virtual PC 6.8 MB per second

I’m not surprised that this makes a big difference to perceived performance, since Windows spends much of its time reading and writing temporary files. This may also be why VirtualBox seems to start up and shut down much more quickly.

I don’t claim that my informal tests prove that VirtualBox is a faster performer in every case. Maybe there is some setting I could change that would improve Virtual PC’s speed; or maybe Virtual PC likes some hardware better than others. Still, it is a real-world experience, and enough to make me suggest that you give VirtualBox a try if you have yet to do so. By the way, both these products are free.

Finally, let me note that Vista running directly on the hardware scores a PassMark of around 1100 on this machine. Even VirtualBox is a lot slower than the real thing, as it were.

Update: If you try VirtualBox, make sure you get at least version 1.6.2 (6th June 2008), as 1.6.0 has broken networking on Windows.

Related posts:

1. VirtualBox: get today’s update
2. Fixing a VirtualBox Windows XP blue screen
3. Hyper-V disk I/O: performance of dynamic vs fixed virtual hard disks