Replacing the Hard Drive of Macbook Pro Mid 2010

One of the bad purchase decisions that I ever made was to buy an Apple product without following its release schedule. Just two months after buying the Macbook Pro late 2010, Apple released the Macbook Pro 2011. The reason why it was a big deal is because the 2011's is so much different with its predecessor. One of the huge difference is that the 2011's supports SATA 3.0 while the 2010's only supports SATA 2.0. This means that if you would enjoy the full speed of SSD 6Gb/s when installing an SSD SATA III 6Gb/s, while installing in the 2010's would result in the negotiated speed of 3Gb/s, given that you install the compatible SSD product.

After searching around in the Google, I finally came to a summarized fact that Macbook Pros before 2011 came with a buggy graphic card - NVidia MCP89 AHCI. Many people reported that they only got the negotiated speed of 1.5 Gb/s (same speed as a SATA drive with 7200 rpm, which makes the SSD upgrade looks like a joke) when they installed an SSD with SandForce controller. Apparently buggy graphic card plus buggy SSD controller means speed cut in half. Many SSDs in fact, use SandForce as the controller, so you would want to be careful in choosing the correct SSD. For example, Crucial BX200 240GB SATA 2.5" 7mm (with 9.5mm adapter) Internal SSD and other variants, are guaranteed to be compatible with MacBook Pro Mid 2010. A lot of people fancy the Samsung SSD 850 EVO, but I just wouldn't risk an incompatible part.

 Replacing the hard drive is very simple, just unscrew the back body of the Macbook Pro, and then locate the hard drive, and unscrew 4 screws that hold the hard drive together (as shown in the picture), pull out the old drive and detach the cable. You might need to use the extension from 7mm to 9.5 mm that came with the SSD if it's a 9mm drive since the slot here is for 9.5mm drive.

Regarding the content of the drive (OS and data), I saw 3 options here:

1. Copy the image of the entire old hard drive to the new hard drive using `dd` and a SATA to SSD cable. If the size of the old hard drive is smaller with new drive, you might need to create drive partitions on the new drive, for example: 128GB for the content of the old drive, and 128GB empty partition. 
2. Use the migration software that usually comes with the SSD, here you would also need a SATA to SSD cable. 
3. Create a Mac OS bootable drive, then install new OS from scratch on the new hard drive. Migrate just the data through an external hard drive. 

Since I don't own a SATA to SSD cable, so I just did the last option, which is not too bad because a fresh install might speed up the system too.

To create a Mac OS bootable drive, prepare an empty pen drive with capacity of more than 8GB that is formatted with (Journaled) HFS+. Then open the App Store and install "OS X El Capitan", which will take a long time because it will download around 6GB of data. Once it's done, open the terminal and run this command:

/Applications/Install\ OS\ X\ El\ Capitan.app/Contents/Resources/createinstallmedia

It is also possible to do an Internet recovery and directly install Mac OS online without having to create a bootable pen drive.

Replacing the Battery of Macbook Pro Mid 2010

My old Macbook Pro that I have been using since Jan 2011 has never had a good battery life since a few years ago. It might be because I have been abusing it with dual boot or I never care to unplug it from the power.

I wish there is a free app for OS X that could automatically stop the power in some scheduled time so that the battery is always exercised to charge and discharge. I know there is an application that does exactly this sort of thing on Lenovo Thinkpad called ThinkPad Power Management.

Changing a Macbook Pro's battery is very simple, what you need are only a replacement battery, a plus screwdriver, and a tri-wing screwdriver. First, shut down the MacBook and then unscrew all the screws off the back lid using a plus screwdriver. Lift the lid and don't be surprised with the amount of dust that has accumulated there.

Next, just unscrew the 2 screws on the battery with a three-wing screwdriver. Then, unplug the socket to disconnect the battery from the laptop, which should be easy if it's picked from the correct angle. Lift the battery and then install a new replacement battery there.

It takes less than 10 minutes and would save you 2 trips to Apple Care, not to mention the days where the laptop has to stay with them.

Thesis

This thesis program is the result of my work from Dec 2014 until around Mar 2015. It is a parallelisation of swarm - an existing single-linkage clustering algorithm for metagenomics data. This program arranges the complete hierarchical clustering workflow into of a set of finely-grained computations (referred as row calculations) that can be run in parallel. The concept of "subseed" was re-used from swarm to skip most of the redundant comparisons (referred as economic search).

The code for global pairwise alignment and k-mer filtering scheme were also re-used from Swarm since they were proven to be very efficient with the SIMD utilisation.

Based on the tests that were run on medium sequence length dataset (averagely 381 nucleotides), the speedup that can be achieved through the parallelisation is averagely 11 times when using 16 threads. This result indicates a successful parallelisation technic which according to Amdahl's law it means 97% of the code were able to be parallelised.

4 level economic search

sequence distance triangle inequality

And the full document:

Is write to disk faster than write to memory? Don't think so

Not long after being featured in IT World, this paper went viral in Slashdot.

Code was written in different language: Java and Python and this paper claimed to prove that "in-memory DOES NOT always work faster than disk operation". I couldn't help but to read the code because it cannot be true.

First of all, the code is not proving that memory operation is slower than disk operation.

First part of the code repeatedly concatenate the String object "1" as a single byte using `concatString += addString` which is a proven inefficient way to do it (mentioned in every Java programming book). This is irrelevant with memory operation being slow.

Second of all, what "Single Write to Disk Time" does is actually not an in-memory operation. This is just the time used to write an object of a very big String (length of 1,000,000) into a file. What will happen is that CPU will fetch buffers of data from RAM and then pass it to the file.

The part "Write to Disk Time" that is claimed to be faster is the part where "1" is repeatedly written to BufferedWriter for 1,000,000 times. Of course it will be faster because "1" will be stored in CPU cache since it's used for 1 million times and fetching from CPU cache is very fast because the data is already there in the CPU.

It is not a surprise that reading "1" from CPU cache for 1,000,000 times is faster than reading a String containing 1,000,000 of "1"s from the RAM.

So, no, disk operation cannot be faster than memory operation.

OTOH this could also remind us how important it is to validate any research paper before citing or referring from it.

Setting up Valgrind on Mac OS Yosemite

Valgrind is a popular tool for debugging memory leak in C++. By using this tool you will be able to see objects that were forgotten to be freed/deleted, and potential bug from code that Valgrind doesn't like.

Installing Valgrind on older Mac OS is very simple and can be done from brew. However the most recent Mac OS 10.10 (Yosemite), has not been officially supported by Valgrind. Hence to be able to use this, installation must be done manually from their latest svn trunk which is also very simple.

svn checkout svn://svn.valgrind.org/valgrind/trunk

Followed by going into the directory trunk and:

./autogen.sh

make

make install

While running autogen.sh one might get an error saying that aclocal was not found.

./autogen.sh: line 6: aclocal: command not found

error: while running 'aclocal'

In this case the automake needs to be installed prior to running this script. The easiest way to do it is to install from brew, such as:

brew install automake

To start using valgrind:

valgrind --leak-check=full --show-reachable=yes --log-info=leak.log "[your program and args]"

For less detailed information and log to stdout:

valgrind --leak-check=yes "[your program and args]"