New 27″ iMac Retina benchmarks and speed tests – OS X & Windows 8.1

So after many years of use I’d decided to retire my 20″ 2007 iMac which was starting to show it’s age even with an upgrade to 4GB of ram and from an internal hard disk to SSD and the Superdrive replaced with a 1TB 2.5″ spinning disk.

After seeing the release video for the new iMac on the 17th my interest was piqued enough to pull the trigger and order one.

I wanted the 4Ghz i7 and really once you’ve gone SSD there is no going back, so I didn’t want to risk the fusion drive. (Apple’s software wrapper for an internal 1TB spinning disk and a 128GB PCI-E SSD.)

Instead I plumed for the 512GB SSD, 8GB of RAM with more ordered from Amazon. The one concession I made was to not get the upgraded graphics card, the AMD M295X, instead getting the base AMD M290X.

As it turns out, I am eligible for an educational discount and as such I’ve initiated a return to Apple of the machine I have with an almost identical one ordered with the upgraded M295X.

This gives me the perfect opportunity to benchmark both and compare the results.

Here is the first collection of results for the following benchmarks, unigine valley, unigine heaven, 3dmark firestrike running in both OS X yosemite and Windows 8.1 Enterprise running in boot camp where applicable.

The benchmarks are all run in the highest possible preset available in the free version. This is to ensure that the result are comparable to other machines and not obscured by a myriad of custom settings. I will try and do some hi-res benchmarks at some point as I understand that with this machine especially, there would be interest in this.

The Windows 8.1 benchmarks are something I’ve not seen may other places.


Late 2014 – 27″ iMac i7 4790K 4Ghz, 16GB, 512GB SSD, AMD M290X

Unigine Valley – Extreme HD – OS X – 1096

Unigine Valley – Extreme HD – Win 8.1 – 1302

Unigine Heaven – Extreme – OS X – 659

Unigine Heaven – Extreme – Win 8.1 – 841

3dMark Win 8.1  – 5319

You can watch the actual benchmarks and my commentary on Youtube.

Part 1

Part 2

Part 3

You can also watch an incredibly unscientific video of my opening every app in the applications folder at once. (hint the iMac doesn’t break a sweat). Here

Macbook down!

Yesterday was a sad day for me. It was the day that my trusty and hardworking Macbook Pro finally expired.

To be fair to it, I could have treated it better, it was grubby and worn at the edges, it’s aluminium bent and frayed from it’s short but brave life filled with perilous adventures. It had barely ever been allowed full REM sleep, only the type you get with one lid closed. Waiting eagerly to resume it’s task within seconds of my call.

It had done the donkey work of a beast much larger than itself after me having cast aside desktop computers two years ago after having quite spectacularly destroyed my previous one in a death worthy of a hero. A death filled with blue sparks and flame.

For one who had lived life on the precipitous edge its end as it would come had been somewhat underwhelming.

It was happily chugging along, Debian and Solaris VM’s running in the background, a few ssh shells open along with 50 or so tabs open in Chrome and then with the blink of an eye appears the Apple gray screen of death.

I power it down and turn it back on, my ears pleasantly relived by the reassuring whir of fans, hard drive spindles and the cha-chunk of the cd-drive but my hopes are just as soon dashed when I fail to hear it’s yawning chime and it’s face light up with radiant colours.

Instead it sits there, brain-dead, soulless, breathing yet unable to perform.

Today I took it apart and isolated out all removable parts. Leaving the only possible culprits the logic board or it’s integrated graphics card.

Upon doing some research I find out that there is actually a known problem with a batch of Nvidia 8600GM’s present in some Macbook Pro 2.4Ghz models and that due to an unexpected failure rate apple has extended the warranty on effected units to 4 years along with free repairs. The problem seems to have been nicknamed the ‘Black screen of death’ and although this all sounds great, noises from forums and the blogosphere don’t seem to indicate the situation is as perfect as it seems.

Many seeming to have hit and miss results in actually claiming their free repair or having be charged upfront and then having had to demand a refund upon finding out that the problem is a known one and that they are entitled to their money back.

Here is a link to the Apple article laying out the details of this problem,

I’ve seen reports of those who had screen or files sharing enabled having still been able to access their machine remotely or by having booted the it in to target disk mode and retrieve their data that way.

Myself, seems as I’d had it striped down, I chose to stick the hard drive in my external disk cloner/caddy and connect it via USB to another machine and pull off the things I’ll need in the coming few days until repair.

So, has this happened to you? What was your experience in getting it repaired? Did you manage to get it done free of charge first time or did you have to battle?

Mine is being picked up by courier tomorrow and  am hoping for a smooth resolution.

Until then I’m stuck on a tiny and underpowered netbook hooked up to my 28″ monitor. As I type this I’m currently installing a Debian VM on it so I don’t have to miss out on my Unix fix.

Watch this space.

TKinter – Delving in to the world of Python GUI’s.

So today I’ve set myself the task of getting to grips with GUI’s in Python.

I’ve started as I always do with a google search and I now have about 50 tabs open, waiting for me to pluck up the courage to start delving through the mass of information and trying to sort the cruft from invaluable.

So far I’ve found that I can forget about wxWidgets as there is no sign of Python 3 integration in the near future. This leaves me it seems with only TKinter and possibly QT4/PyQT…….

Anyone know different?

Stay tuned for my next blog, where I’ll detail what I’ve found and which websites I found useful.

I’ll also soon blog about why I’ve decided to go with Python 3, rather than the more mainstream and accepted 2.xx.

Installing Python 3.1 from Source code on OS X with readline

So I recently took it apon myself to try installing Python 3.1 from source code on my Mac laptop.

As soon as ‘make’ had finished I was presented with a message telling me that several libraries which would be required for extra functionality were missing.

One of these was ‘readline’. If you don’t know what ‘readline’ does, it provides the functionality inside the Python interpreter similar to that in Bash or Doskey. Just to mention one of the small but important feature it allows you to be able to press the up and down arrow keys to scroll through previous input. If you intended on using the Python interpreter interactively this is pretty much an essential.

OS X does not contain the GNU readline library and instead uses a replacement called editline due to licencing issues.

It’s been a few days since I performed the install but I hope my memory serves me correctly in detailing the steps necessary to get Python compiled and using the readline library. Please leave comments to the contrary if you believe I’ve missed out any step and I will try to plug-in the blanks.

Please note, to compile programs from source on OS X you will need to install X Code from Apple. This is the Apple development environment which bundles their IDE, libraries and such along with the GNU C compiler GCC.

The first thing I needed to do was to download the ‘readline’ library. I did so by downloading readline-6.1.0.tar.gz from

Once downloaded and extracted, I opened up the terminal and navigated to the ‘~/readlin-6.1.0/readline/’ directory.

Here I ran the command ‘./configure’, this checks your environment for prerequisites required for the compilation and then configures the make file for the build as appropriate.

Once this has completed successfully, you should run now run the command ‘make’. Again this should be done from the terminal in the same directory as before. Your computer will now be compiling the ‘readline’ library.

Presuming all steps have been successful so far you can now type, ‘sudo make install’, again from the terminal in the same directory. You will require admin permissions for this due to files being copied to protected directories. You have now installed the ‘readline’ library we have just compiled.

Now that we have built and installed the library, you can go back to your Python source code folder and compile and install Python 3.1 as instructed in the Python documentation.

All going well, you will now notice that at the end of the compile it will no longer complain about ‘readline’ being missing and your Python interpreter, will now work as intended with the correct functionality.