Is Adobe self-sabotaging their PC products?
It should come as no surprise to those of us who are involved with the development of the web that Adobe is selling software for the Apple Mac faster than ever.
One might be reminded of their publicity blunder a few years back now, where Adobe – a long time Apple partner – quite publicly admitted “PC’s are faster”.
However, it appears times have changed. Adobe no longer carry the “PC Preferred” flag, and it is quite obvious that Adobe is seen as a spearhead developer for the Mac platform (a fact which is recognised and exploited by the most unscrupulous of tech-wise individuals).
It is also quite painstakingly obvious that Adobe have completely missed the target with their CS3 and CS4 software for Windows, where their software suite is highly unstable, bloated, and sluggish.
To quote an old friend of mine; “I’m pretty much entirely on mac nowadays. [..] the stability of the adobe suite on mac hardware is impossible to beat on a pc.”
He’s absolutely right, of course. Adobe’s software performs faster and a lot more reliably on a Mac, despite the PC’s technological superiority. Some may argue that the difference is platform specific, but as a developer I dispute this. I don’t dispute, however, that it’s possible (and common practice) to target code optimisations for a specific platform.
It’s not just poor PC code and crashes that are the issue, either. Things which have been totally broken on the PC in Premiere since version 6 remain broken, such as the AVI export feature (DV works.. everything else? not a sausage.)
The title of this post may be misleading, since I’m more talking about Adobe apparently directing their development team resources away from the PC and towards the Mac as opposed to any act of internal sabotage, but the net effect is the same.
Anyway, rant over. I’m a PC enthusiast, with plans to purchase a Mac in the short term for the purpose of compiling applications. I’m always going to be a PC enthusiast, I think.. the lack of upgradeability and things to tinker with on the Mac will probably bore me rather quickly.
Clash of the unlikely: C# versus.. RealBASIC?
As an Opensim developer, I use C# with .NET or Mono on a daily basis. To be honest, I love the language. It’s clean, efficient and simple.
Yesterday however, I suggested on IRC that whilst C# has definately benefited OpenSim with its simple debugging, rapid development and wide selection of prebuilt classes to choose from, it was not a great choice for what is, essentially, a high performance application.
Upon stating this, a couple of people chirped up to tell me that while a language like C or C++ would provide better performance, I would be suprised how far JIT compilers have come.
I decided to put this to the test. Hopefully, I supposed, I would be proven wrong and the performance of C# would very much impress me. But I didn’t want to prove what had already been proven (that is, C and C++ will outperform C# every time), but I wanted to pitch a performance comparison against an unlikely competitor, one which most definately isn’t seen as a “professional” language and hardly ever considered for real applications.
Enter RealBASIC. This commercial product from RealSoftware contains a vast featureset of prebuilt classes and modules, very similar to .NET, and its rapid compile system will spit out native code for Mac, Linux and Windows in one swoop. Of course, it’s not an open specification (which is why it’s not considered for serious uses) and the IDE can set you back a very steep €400.
Why did I choose RealBASIC? Because it’s a development environment with a lot of overhead, BASIC is widely considered as being extremely slow, and it has built in functionality very similar to that available with .NET.
So, I decided to write a simple test to guage the performance between the two systems. Randomly generate one million UUID’s and place them into a dictionary, first performing a lookup to ensure there are no collisions.
You can see the C# code here
You can see the RealBASIC code here
All tests were performed consecutively, alternating between C# and RealBASIC. Both were with “release” executables, without debug info. Both were targeted at x86. I don’t think I could have predicted the result.
C#
40.971 seconds, 1,000,000 keys in dictionary (0 collisions)
39.773 seconds, 1,000,000 keys in dictionary (0 collisions)
42.466 seconds, 1,000,000 keys in dictionary (0 collisions)
RealBASIC
25.876 seconds, 1,000,000 keys in dictionary (0 collisions)
25.425 seconds, 1,000,000 keys in dictionary (0 collisions)
25.555 seconds, 1,000,000 keys in dictionary (0 collisions)
I think that these results just go to show that JIT compiled languages have a long way to go yet, before they are really appropriate for high performance applications.
I would like to point out that I am NOT suggesting that anybody use RealBASIC, i’m not suggesting that Opensim should have been coded in RealBASIC, it just seemed like a fair comparison to me. I do think that C# is a powerful language, and .net is a decent platform, and there are far more evil languages out there. If we were to perform this test on Java, these results would have been in the hundreds.
~T
Ultra low lag AOs now in Opensim!
Anyone who is familiar with Second Life will have felt the same feeling at least once during their metalife.. “Why don’t they do this? It’s so easy, and would improve things massively!”
One instance where a small amount of work has the possibility to make a big change to user experiences, is improving Animation Overrides (AO’s). These are user created scripts which automatically replace the default animations as avatars move around.
Traditionally – due to limitations within second life – these scripts have needed to run checks constantly; often several times a second. Needless to say, they are often the cause of a lot of lag and general load on the simulator.
Melanie – one of the core developers of Opensim – has taken the torch, raising the bar by providing a script event which actually notifies the script when an animation state changes. Not only is this a big step towards reducing lag within the metaverse, but it also benefits end users directly by providing faster and more seamless animation state changes.
Melanie said “I looked at implementing it [before, but] despaired and did easier things. [A change to the code yesterday] made it possible to actually do it”.
Major texture processing rewrite for Opensim
So there I was, standing on my sim on newly rented hardware, hooked up to OSGrid. As I had unfortunately grown accustomed to on Opensim implementations, my avatar had only partly baked, there were several blobs which perhaps had a view to maybe one day becoming sculpties, and anything I rezzed from my inventory seemed to turn out grey and rather dull looking.
I knew that not everyone had as much trouble as me with this, but I soon found out from OSGrid IRC that I wasn’t the only one who had issues with the texture pipeline stalling.
As part of my work with Remedy, I am constantly looking for ways to improve the performance and stability of Opensim, and so naturally I opened up the source code to see if anything needed changing.
As I started tinkering, adjusting things, trying to work out what was causing the issue, it became apparent that the code that was there could do with a little work. To cut a long story short, I ended up re-writing the module, using some of Teravus’ old code for byte positioning calculations and such.
And i’m pleased to report that it turned out to be a great success. The patch was submitted on 2009-04-09 22:03, and was committed 3 and a half hours later by Teravus, the original author of the code that it replaced.
The improvements made by the patch are:
- Increased texture load speed by 200-300%
- Increased packet efficiency greatly, less wasted bandwidth
- Shaken the texture clog issue where textures stopped being delivered
- Implemented texture priorities properly, nearer objects load first
- Reduced memory usage per connected client VERY substantially.
At time of writing i’m starting to get a little feedback as people update to the latest code..
<FrankNichols> just updated to head, first impression of new texture processing – big improvement and so far no negative side affects – mono 2.4, linux 32b.
I put together a little video showing off the difference. Click here to watch in high def for best enjoyment 
