I’ve been contemplating a new Macbook Pro for a while, mostly because my Macbook Air with it’s 4GB of RAM and 128MB of SSD were just getting too cramped. The battery is getting tired as well, giving me “only” 2 1/2 – 3 hours of life before dipping into the 10% range (First world Apple problems, most Windows laptops don’t see 3 hours when they’re brand new). But mostly it was the 4GB of RAM. I would routinely run up 8GB of swap space which would then eat into my almost full SSD space.
Now one of the features of Mavericks is Compressed Memory, which intrigued me a bit. Well, after a day of usage, I’m only using 40mb of swap, when normally I’d be off into the 4GB range:
On top of that, before the installation started, I had ~9GB of free disk space (with a 8GB swap file active). The install was 5GB but I figured I would recover some back. After the install finished? 36GB free! I must have had some major cruft laying around from 10.8, but I won’t complain about 20+GB of free disk space.
I haven’t had a chance to test the battery life increases yet, as I’m mostly tethered to a desk, but with WordCamp Boston coming up this weekend I should get a pretty good idea what the improvements there are.
Another lesson in automated deployments. This time related to high frequency trading. The biggest WTF is near the end:
Knight did not have supervisory procedures to guide its relevant personnel when significant issues developed.
In one of its attempts to address the problem, Knight uninstalled the new RLP code from the seven servers where it had been deployed correctly. (But not from the 1 server that was causing the problem)
…recommends new human processes to avoid a similar tragedy.
Also related is the HN discussion with other cringe worthy anecdotes.
The week after this we had a trader in our office who had a meeting at Knight on the morning it happened.
The craziest thing is that it went on for so long. No one caught it until their own traders so it come across Bloomberg and CNBC. They actually thought it was a rival HFT and tried to play against it.
LAME is my perferred MP3 encoder, but it’s kind of slow, even on my dual-cpu G5. Now, the G4 and G5 processors have a special instruction set called Altivec which should, in theory, speed up certain tasks. Photoshop, Final Cut Pro and even Apple’s own iTunes take advantage of this. LAME does not, but I was thinking that it should. I’m currently using LAME installed from sources from Fink, so I thought I was getting a somewhat optimized version. I was wrong. After a little searching I found this page that has some flags to use when you compile LAME from source (it’s really easy, don’t worry). You don’t have to use the ones in the main article there, scroll down a bit and there’s a simplified version:
./configure –enable-static –disable-shared CFLAGS=”-fast”
Then a “make” and “sudo make install” and you’re all set. Here’s the results of a test I performed on a 2:14 .wav file (rock song, fairly complex) with various encoding settings (CPU time in minutes:seconds. lower is better, kbps shown for VBR modes):
Fink Version (3.93)
preset standard – 1:35 (217.2 kbps)
preset fast standard – 0:46 (210.0 kbps)
preset extreme – 1:30 (240.0 kbps)
preset fast extreme – 0:48 (235.2 kbps)
preset insane – 0:43
preset cbr 128 – 0:56
preset cbr 192 – 0:53
preset 128 – 0:57 (123.6 kbps)
preset 192 – 0:52 (189.7 kbps)
G5 Optimized (3.96.1)
preset standard – 0:16 (204.7 kbps)
preset fast standard – 0:11 (226.0 kbps)
preset extreme – 0:15 (249.3 kbps)
preset fast extreme – 0:11
preset cbr 128 – 0:12
preset cbr 192 – 0:12
preset 128 – 0:13 (125.5 kbps)
preset 192 – 0:11 (191.8 kbps)
As you can see, there’s a 4-6x speed up across the board. This is not taking into account any additional speedups in the code from version 3.93 to 3.96.1, but I can’t see it making that big of a difference.