Microsoft and Intel announced today that the two companies have agreed to work together to bring support for Silverlight 3 to Intel’s Atom-based Mobile Internet Devices (MID). These Atom-based devices run on Windows and Moblin, an open source, Linux-based operating system targeted at Atom-based devices. In order to help bring Silverlight content to these devices, Microsoft has provided Intel with Silverlight source code and test suites, and Intel will provide Microsoft with an optimized version of Silverlight for Moblin devices that Microsoft can then redistribute to OEMs.

Since then, Moblin has merged with Novell’s Maemo to form MeeGo (though this is still work in progress), and we’ve heard very, very little about Silverlight on either platform. The only snippet of news I have is that it was mentioned at the Intel Developer Forum in Beijing and reported by Char Zvolanek, who said that it came up in the Meego Q&A after regular sessions ended, and Silverlight will be supported in Meego  version 1.1 in October:

In May, the 1.0 version will be released, and with 1.1 coming out in October, there will be support for Silverlight, Java, and Air. Developers can write native or runtime apps that can be Java-based, Web-based, Silverlight-based, or Air-based.

Today, another clue, but not a good one for Silverlight. Intel is holding an application lab on May 26th in San Jose, for developing for the Intel AppUp store, either on Windows or Moblin. On the agenda: C/C++ and Adobe AIR, and the upcoming Adobe AIR SDK for Moblin. No Silverlight.

If anyone is going along, and can discover any news about Silverlight on Moblin, I’d be interested to know.

Related posts:

1. Nokia Maemo, Intel Moblin gives way to MeeGo
2. Silverlight (and AIR) for MeeGo Linux coming in October?
3. Microsoft brings Silverlight – not Mono – to Linux via Intel

Since then I have been watching for more news about this Silverlight port, but heard nothing. Then in February Moblin merged with Nokia’s Maemo to become MeeGo. What next for the Silverlight port?

Earlier this week I met Intel’s Uli Dumschat at the company’s software conference in Barcelona. He spoke on Intel’s software development products for Atom-powered devices such as those running MeeGo. I asked him about Silverlight for MeeGo and he knew nothing about it.

It seems I was at the wrong conference. Today I spotted this post from Charlene Zvolanek at Intel’s Developer Forum in Beijing:

In May, the 1.0 version will be released, and with 1.1 coming out in October, there will be support for Silverlight, Java, and Air. Developers can write native or runtime apps that can be Java-based, Web-based, Silverlight-based, or Air-based. Even though it’s open source, Intel has been working closely with Microsoft to make sure that MeeGo and Windows are friends.

I also watched the keynote from Intel’s Renee James, who said that MeeGo devices are expected in the “second half of this year”, though I imagine they will be 1.0 devices – who knows, maybe 1.1 will be an upgrade option later.

So Silverlight on MeeGo now has a date. Is this Silverlight 4.0? Will it run out of browser? Access to local resources? Does this date apply to MeeGo Smartphones as well as netbooks? All good questions, about which I know nothing. Watch this space.

Related posts:

1. What is happening with Silverlight on Intel Moblin/Meego?
2. Nokia Maemo, Intel Moblin gives way to MeeGo
3. Microsoft brings Silverlight – not Mono – to Linux via Intel

He was surprisingly (to me) forthright.

It’s not valid. It’s misguided. Intel’s compilers are very high performance. If you use our compiler, you’ll get better performance on Intel or AMD processors than if you used anyone else’s compiler. That’s always been our goal. We believe – I’ll use the words “in general” and that’s a legal disclaimer – in general we’re better. Why don’t I say always? Always is an absolute. Nobody is “always” anything. We are as close to always as we can figure out to be. We have many customers that use our compiler, ship code, because they believe it gets the best performance on Intel and AMD. We will back that. If you find that our compiler is getting less performance on AMD than someone else’s compiler, we consider it a bug. That includes AMD processors.

We settled the suit with AMD, we agreed that we wouldn’t do things we were accused of in future – well, we didn’t do them before. There’s a lot of proof points. AMD used our compiler for benchmarking for a long time. They didn’t do that because we were lower performance.

There are a lot of technical nuances, details of what we do in our compiler that are confusing. One of the challenges is how do we produce a binary that runs best on Nehalem, and on an older Intel processor, or on a processor that supports SSE 2.0 but not 3.0? We have technology in our compiler to try to adapt to that. We mix into that blend AMD, because AMD processors have different capabilities, in the same way that our processors have different capabilities from each other. Yes, people will say, “hey, your compiler’s checking for an AMD processor”. Yes, absolutely, we also check to see if we’re on a Intel processor that only supports SSE 2.0. We have to. AMD processors don’t support the same instructions we do. Our processors have a lot of variety too.

The short answer is that we didn’t do what we’re accused of, we’re very serious about being an excellent compiler for AMD as well as Intel, and this extends to our libraries too.

So that’s telling them. Is he correct and it was a misguided complaint? Well, as I mentioned previously, there are issues of disclosure as well as performance if you are publishing benchmarks; and it is hard to believe that Intel devotes equal effort to optimisation on AMD processors as for its own. Nevertheless I respect Reinders and don’t dismiss his statement. Perhaps Intel’s compiler is OK for AMD after all.

Related posts:

1. How Intel’s compiler underperforms on other CPUs: artificial impairment versus failure to optimise
2. US Federal Trade Commission sues Intel
3. It’s not just free software that has poor usability

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. What is happening with Silverlight on Intel Moblin/Meego?
2. Silverlight (and AIR) for MeeGo Linux coming in October?
3. Hands on with Intel Moblin

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. Intel’s compiler is best for AMD too says software director
2. US Federal Trade Commission sues Intel
3. Bloor on the failure of antivirus products

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. Intel’s compiler is best for AMD too says software director
2. How Intel’s compiler underperforms on other CPUs: artificial impairment versus failure to optimise
3. Microsoft sues Salesforce.com for patent infringement – but why?

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. What is happening with Silverlight on Intel Moblin/Meego?
3. Microsoft brings Silverlight – not Mono – to Linux via Intel

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. What is happening with Silverlight on Intel Moblin/Meego?
2. Microsoft brings Silverlight – not Mono – to Linux via Intel
3. Silverlight (and AIR) for MeeGo Linux coming in October?

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. Anders Hejlsberg on functional programming, programming futures
2. Functional programming, NOSQL themes at QCon London
3. Adobe AIR: 10 reasons to love it, 10 reasons to hate it.