Even on my MacBook Pro, a dual core box, setting the Silverlight version to 4 threads yields about 45 FPS. Clearly the multithreading code has a very significant impact on computationally intensive applications where data parallelism is possible.

Sidebar: Since the original posting I’m now running SL4 Beta 1, and performance of this application is consistent with SL3 release.

In this SL3 Quake demo, the frame rate is not affected by AIR apps: http://www.innoveware.com/ql3/QuakeLight.html

Something like the strange attractor application is going to be particularly sensitive to CPU contention. Not many apps are so completely CPU bound. Things like 3D renderers, programs that encode music or video, operations like HDR Merge in Photoshop, those things are sensitive to CPU contention that might not be noticed surfing the web or writing email.

Back with some news. Accidentally I discovered how to reproduce the slowdown. It’s when I have certain Adobe AIR applications running with visible windows, the concurrent SL3 version significantly slows down. When the AIR app is minimized or terminated, speed is back to normal. “Naive” SL3 version seems to be always OK.

You can eventually try It yourself, one of the AIR apps slowing things down is “thwirl”, a Twitter client, try multiple open account windows. Also the Times Reader slowed it down. Another app, Balsamiq, did not slow it down. It eventually depends how the app authored.

I have AIR 1.5.2 installed. Interestingly the slowdown affects both FF and IE, so this is not a browser issue.

You’re right, I didn’t read the code thoroughly Nor did I read the previous comments thoroughly. That’ll teach me eh? It appears you are doing everything that I had mentioned, and your comments re: the browser are indeed appropriate.

Next time, I promise to make sure i read things properly before stating stuff that’s already been done!

Cheers!
OJ

I not sure you looked at the code carefully enough; if there were 90,000 work items, we’d be talking about frames per minute or hour not frames per second!

If you review the ParallelFor() method you’ll see that the pixels are indeed being divided between the threads, and there are the same number of AutoResetEvents as the number of threads.

The number of threads is dictated by the last parameter of the ParallelFor() function, which is driven by the value of the slider. The best performance comes from roughly 2x the number of cores, or 4 threads on a typical dual core box, and 8 from a quad core box.

Setting the number of threads to the number of cores exactly doesn’t produce the best possible frame rate. Slightly higher is better, the renderer will achieve the best balance of favorable scheduling of its threads and the penalty of context switching.

The slider allows you to split the work up into as many as 64 threads, which does indeed bring the frame rate down. The point is to show the effect of attempting to use too high a degree of parallelism.

With regards to the blaming of the browser – Kaspar experienced significantly different behavior running the same component in his particular environment with two different browsers. The browser version was the only (apparent) variable between the two different sets of behavior, which would make it an excellent suspect when investigating the difference in behavior. It would be prudent for Silverlight, (and Flash) developers to understand that there is a relationship between the plugin and the browser, and what the potential impact of that relationship is.

Thanks for the comment!
-e

Fun examples with great commentary and working source are always good in my book

Silverlight, Concurrency, Functional Programming, Generics – all cool…

You’d be better off dividing your pixel set by the number of physical hardware threads you have on your machine, and getting each one of those threads to work on a subset of the info. You don’t have to worry about contention if you force each work item to deal with its own stuff. Your overheads would drop substantially and you’d probably see at least some kind of performance improvement.

I wouldn’t blame the browser or the plugin. Too much multithreading is often worse than none!

Just my $0.02 Good luck!
OJ