jcBENCH Android Port Released
After some additional work getting used to the XAML-ish layout I'm done with the initial jcBENCH Android port. You can download it from here. You will need Android 2.2 or higher for it to run.
jcBENCH Android
I've only tested this on a Dual 1.2ghz HTC Vivid. However, the results were interesting. Comparing single-threaded and multi-threaded operations was curious. Running it in multi-threaded mode was actually 3 times slower. I'm not sure if the way the Task Parallel Library was implemented on Monodroid was done poorly or if there is a bug in the detection for how many cores/cpus there are inside the Mono implementation or not, but something isn't right. Single threaded versus my HTC Titan 1.5ghz SnapDragon it lost out by ~23%. Which makes sense, 300mhz difference or 20% comparing single cores to each other.
All that being said I'm content with jcBENCH for the moment until I hear feedback or come up with more features to add.
Other jcBENCH news and jcDAL
After some more thought about jcBENCH and what its real purpose was I am going to drop the Solaris and IRIX ports. Solaris has a Mono port, but I only have Sun Blade 100 which has a single cpu. Not expecting a ton of performance from that. IRIX on the other hand, I have a Quad R14k 500 Origin 300, but no port of Mono exists. So I could port it to Java, but then you really couldn't compare benchmarks between the Mono/.NET versions. I am about 50% done with the Android port and am just waiting for the OpenSuse 12.1 compatible MonoDevelop release so I can get started on the Linux Port.
After those 2 ports are completed I am thinking of starting something entirely new that I have been thinking about the last couple years. Those that deal with a SQL database and write a data layer for his or her .NET project, know the shortcomings or doing either:
- Using an ADO.NET Entity Model, adding your Tables, Views and Stored Procedures and then use that as is or extend it with some business logic
- Use an all custom data layer using the base DataTable, DataRows etc, wrap your objects with partial classes and create a "factory"
Both approaches have their pros and cons, the first takes a lot of less time, but you also have a lot less control and could be costly with all of the overhead. Both however will eventually fall apart down the road. The reason, they were built for one audience and one production server or servers. How many times have you gone to your IT Manager and asked for a new Database server because it was quicker then really go back to the architecture of your data layer. As time goes on, this could happen over and over again. I have personally witnessed such an event. A system was designed and built for around 50 internal users, on a single cpu web server and a dual Xeon database server. Over 5 years later, the code has remained the same yet it's been moved to 6 different servers with ever increasing speed.
Times have changed and will continue to change, workloads vary from day to day, servers are swapped in and out, so my solution, an adaptive, dynamic data layer. One that profiles itself and uses that data to analyze the server to use either single threaded LINQ queries or PLINQ queries if the added overhead of using PLINQ would out way the time it would take only using one cpu. In addition using Microsoft's AppFabric to cache the commonly used intensive queries that maybe only get run once an hour and the data doesn't change for 24. This doesn't come without a price of course, having only architected this model in my head, I can't say for certain how much overhead the profiling will be. Over the next couple months, I'll be developing this so stay tuned. jcBENCH as you might have guessed was kind of a early test scenario of testing various platforms and how they handled multi-threaded tasks of varying intensity.
jcBENCH WP7 Release
After a few days wait, I've ported jcBENCH to Windows Phone 7 (aka WP7 or Windows Phone). I've only tested it on an HTC Titan thus far, but all of the WP7 devices released thus far are all about the same specs wise. Virtually all of them have a 1.4ghz or 1.5ghz SnapDragon CPU, 512mb of RAM and all support 480x800. I wish the Titan would have had one of the Dual Core Qualcomm CPUs, maybe in the Titan III 
jcBENCH WP7 Screenshot
All you'll need to run it is a developer unlocked phone and then deploy the XAP file as you would normally.
jcBENCH 0.1.63.0 Released
With this new release I've fixed a bunch of things in Web Service and the main library that powers all of the clients. In addition I'm tracking a bit more information like the platform and benchmark version (thinking more down the road when specific versions are going to change in the logic in the actual algorithm).
Also this release marks the first release of the GUI Mac OS X 10.6 (and later) client.
jcBENCH on Mac OS X
You'll need GTK 2.12 or newer and Mono 2.10.8 or newer to run it. Being my first Mac OS X application ever outside of iOS development, I can without a doubt say I cannot stand development on anything Apple. KVC has got to be the most bloated way of doing things I have ever seen. I am so glad I do not have to do native Mac OS X applications for a living. That being said though, I think it turned out pretty well in matching the WPF version.
New version of jcBENCH tonight
New version of jcBENCH will be coming out tonight, in the mean time I have taken down the web service so you won't be able to submit results. More details to follow...
jcBENCH Analysis
Just benchmarked my netbook, web server, desktop and a few machines at work. Some interesting results, to really take advantage of x number of cores you need operations that are complex and or in a longer duration.
Looking at a 24 Core Opteron server run the same number of tasks was actually slightly slower than my 6 core Phenom II. However, running a task that is 10X longer, the 24 core runs 3X faster. Factoring in that the Opteron cores are 900mhz or 29% slower, that's 4X faster, directly equating to the fact the Opteron had 4X as many cores.
More details as I benchmark more machines.