Monday, March 16, 2009

Benchmarking Python decimal vs. float

I'm writing a web app that includes, among other things, a good amount of (rational) non-integer numbers. Whenever I'm in this situation, and I'm using a language that supports Decimals (as opposed to just floats and doubles), I always wonder which one I should use.

If you're a programmer, you understand the difference and the dilemma. Floats/doubles are very fast, as all computers (built within the last 15 years) have hardware specifically made to deal with them. However, they're not perfectly accurate; because of binary representation, numbers that we use a lot (like 1/10 or 0.1) cause the same problems that 1/3 (0.33333...) cause in base 10.

Decimals, on the other hand, are slow. They are handled entirely in software, and thus take hundreds of instructions to do things that would take less than 10 with floats/doubles. The upside is that they're perfectly accurate; 0.1 is 0.1 is 0.1.

So the question becomes twofold:

  1. Do I really need my numbers to be perfectly accurate?

  2. How much slower are decimals than floats/doubles?



In my case, the accuracy would be nice, but not completely necessary. And thus, the latter question becomes important. I'm not writing a large application, and I don't expect it to get too popular too quickly, so if the slowdown is only moderate, I'll take the accuracy.

To learn what the slowdown was, I wrote two quick Python test programs:


# Decimal test
 
from decimal import Decimal
 
a = 0
for i in range(0, 20000):
    a = Decimal('%d.%d' % (i, i))
    print(a)



# Float test
 
from decimal import Decimal # kept this in on the float version
                            # so they'd have the same overhead
 
a = 0
for i in range(0, 20000):
    a = float('%d.%d' % (i, i))
    print(a)


When I ran each of these with /usr/bin/time (which I just learned about a couple weeks ago, and has replaced counting seconds on my fingers as my favorite benchmarking tool), the decimal version took an average of about 1.5 seconds (over 10 runs), while the float version took an average of 0.5. Just to make sure no overhead was getting in the way, I upped the limit to 40000 and ran it again. Decimal took 3.0 seconds, float 1.0. I can now confidently say that Python floats are about 3x the speed of Python decimals.

Or are they? While this tests the creation and printing of decimals and floats, it doesn't test mathematical operations. So, I wrote two more tests. I'm going to be doing a lot of division on these numbers, and that's definitely the most expensive mathematical operation to compute, so I made sure to do it in the tests (along with some subtraction).


# Decimal version
 
from decimal import Decimal
 
a = 0
for i in range(2, 20002):
    a = Decimal('%d.%d' % (i, i)) / Decimal('%d.%d' % (i - 1, i - 1))
    print(a)



# Float version
 
from decimal import Decimal
 
a = 0
for i in range(2, 20002):
    a = float('%d.%d' % (i, i)) / float('%d.%d' % (i - 1, i - 1))
    print(a)


This time, the float version averaged about 0.6 seconds (1.15 with 40,000 iterations instead of 20,000), while the decimal version averaged over 11 seconds (23 with 40,000 iterations instead of 20,000). So while Python float creation and printing is merely 3x as fast as Python decimal creation and printing, Python float division is almost 20x as fast as Python decimal division.

So what did I choose? Decimals. In the context of these tests, the decimal slowdown may seem significant, but if I finished my app using decimals and profiled it, I can almost guarantee (based on the speeds here) that the bottleneck would not be decimal division performance. If I was running an app that was handling hundreds of simultaneous requests, I may consider switching (I may also spring for better hardware, but that's a different topic). However, for my purpose, 1/20th the speed of floats is more than fast enough.

P.S. As my very late discovery of /usr/bin/time should suggest, I'm extremely new to benchmarking. If anyone has any suggestions for me, or criticisms of my method, please leave your thoughts. This is something I'd like to get better at.

Sunday, March 15, 2009

Why Facebook keeps changing their interface

Facebook has a new design. Every programmer I know loves it. Almost everyone else I know hates it. I could've written those three sentences a couple years ago, copy/pasted them every six months, and they would've fit perfectly every time.

Of course, the pattern has always ended the same way as well. People forget about it within a month, and when the next change comes around, it's "It was PERFECT the way it was, why are you changing it?!"

In fact, I've seen a bunch of people asking "why does Facebook keep changing the interface?" Most people are asking it rhetorically, with the implied answer being "to confuse users." However, if asked honestly, it's actually a pretty good question, with a pretty good answer.

Facebook has gotten where it is today by innovating. Prime example: the News Feed. When they added the News Feed, no one else was doing anything like it. Despite massive user riots, they stuck to their guns. Two years later, everyone loves it, all the social networks have copied it, and there would be massive user riots if they scrapped it.

Facebook has stayed at the forefront of social networking innovation by constantly throwing everything at the wall, keeping what sticks (News Feed), and scrapping what doesn't ("How do you know this person?"). It's in their best interest to do this; they make their money from venture capitalists and advertisers, not from charging users.

If they charged users, changing the interface so often would be a bad move; users would stop paying as soon as they became confused with a new interface, and they'd lose money. As it stands, users who are confused with a new interface can take a break at no cost to Facebook, come back in a few weeks (as they always have), and the advertisers and venture capitalists (who only care about long-term success) are happy.

Obviously, Facebook and its investors have become accustomed to the pattern: make a change, suck up the complaints (possibly while making some adjustments, like the additional privacy options after the News Feed was added), and reap the benefits of being a bastion of social networking innovation for another six months. Eventually, maybe the users will get used to it as well. I've actually seen a few status updates along the lines of "I guess I probably won't hate this so much once I get used to it" after this update, so who knows?

Wednesday, March 11, 2009

Apple takes it too far on form-over-function

Today, Apple announced the new iPod Shuffle. It drops the navigation buttons in favor of making it slightly smaller.

New iPod Shuffle


Your first question upon hearing this was probably the same as mine: "How do you switch songs?" Simple: the controls are on the cable of the prepackaged headphones.

New iPod Shuffle Headphones


Do you listen to your iPod with the headphones it came with? Most people I know don't. Admittedly, I don't know anyone who owns an iPod Shuffle (my mom used to, but that's it), so it's possible that iPod Shuffle buyers often stick with the default headphones. But be warned: if you buy an iPod Shuffle, and you want to use your own headphones, get ready to not be able to switch/skip songs.

I understand choosing form over function, up to a point. But to me, this just seems ludicrous. The difference in size between this thing and the last-gen iPod Shuffle is minuscule, and the functional sacrifice immense. But maybe I just don't get it.

Monday, February 9, 2009

What of the Google monopoly?

Jeff Atwood of Coding Horror made a post about the Google monopoly, suggesting that we should be concerned.

I don't 100% disagree with him, but this section struck me as especially egregious:

I'm a little surprised all the people who were so up in arms about the Microsoft "monopoly" ten years ago aren't out in the streets today lighting torches and sharpening their pitchforks to go after Google. Does the fact that Google's products are mostly free and ad-supported somehow exempt it from the same scrutiny?


This is an interesting argument, but there's one critical difference: Google does not partake in monopolistic activities.

One of the big problems with Microsoft was when they pre-installed Internet Explorer on Windows with no way to remove it, leveraging their OS monopoly to gain an unfair advantage in the browser market. They got sued, added a "remove software" option to let people remove pre-installed software (IE, Windows Media Player, etc.). Now, even though their OS market share has barely shifted (definitely under 5% shift), few people complain about their monopoly anymore.

I'm not saying they're okay now (or even that what Google's done is in the best interest of the internet), but the reason no one complains about Google's monopoly is because they created it legitimately, and they don't do evil things with it.

Friday, December 12, 2008

Scraping the Bottom of the "Developer Productivity" Barrel

Patrick Smacchia writes a blog post about how buying a Solid State Drive will produce a worthwhile increase in developer productivity.

He cites a few self-run benchmarks. A couple are impressive: a certain build shaves off 2 minute and 14 seconds (a little under 50% faster), and running 1846 NUnit tests brings a 2 minute and 40 second process down to 37 seconds (about 80% faster). The rest... not so much. Most are cutting scant seconds off of already quick processes.

I do believe that there are some expenditures that are worth it. Developers spend 8 hours a day sitting, so buying them extremely comfortable chairs makes a huge difference. Similarly, developers spend 8 hours a day looking at their monitors, and buying them each two large monitors allows them to keep their work and minds better organized.

This SSD claim does not seem to pass muster. Look at the difference. An internal 80GB Intel SSD costs $559.99. How much does a normal 5400RPM internal 80GB drive cost? Well, I can get this Western Digital one for just over $40.00.

That means the Intel one costs almost 14 times as much. If I'm buying this for my developers, I want to make sure it's cost-effective. Let's say I pay my developers an average of $52.00 per hour (to make the numbers easy). That means, to justify the extra $520.00 I'm spending to get this SSD, it needs to save them 10 hours over the course of their time with me. That's 268 of those builds mentioned earlier, or 293 of those sets of NUnit tests.

Is this an outrageous number? No. But it's also not an obvious win, like buying a pair of large monitors or a comfortable chair. It's scraping the bottle of the barrel, to say the least. Unless he's got a super awesome chair, a couple 24-inch monitors, and all the other productivity staples, I'd say his money would be much better spent elsewhere.

Monday, December 8, 2008

Great Analogy for Entrenched Social Norms

I'm stealing this analogy from a blog post by core Django contributor James Bennett. I think it's brilliant:


There's an old joke, so old that I don't even know for certain where it originated, that's often used to explain why big corporations do things the way they do. It involves some monkeys, a cage, a banana and a fire hose.

You build a nice big room-sized cage, and in one end of it you put five monkeys. In the other end you put the banana. Then you stand by with the fire hose. Sooner or later one of the monkeys is going to go after the banana, and when it does you turn on the fire hose and spray the other monkeys with it. Replace the banana if needed, then repeat the process. Monkeys are pretty smart, so they'll figure this out pretty quickly: "If anybody goes for the banana, the rest of us get the hose." Soon they'll attack any member of their group who tries to go to the banana.

Once this happens, you take one monkey out of the cage and bring in a new one. The new monkey will come in, try to make friends, then probably go for the banana. And the other monkeys, knowing what this means, will attack him to stop you from using the hose on them. Eventually the new monkey will get the message, and will even start joining in on the attack if somebody else goes for the banana. Once this happens, take another of the original monkeys out of the cage and bring in another new monkey.

After repeating this a few times, there will come a moment when none of the monkeys in the cage have ever been sprayed by the fire hose; in fact, they'll never even have seen the hose. But they'll attack any monkey who goes to get the banana. If the monkeys could speak English, and if you could ask them why they attack anyone who goes for the banana, their answer would almost certainly be: "Well, I don't really know, but that's how we've always done things around here."

Best Virus Email - Ever?

I just received this email (I don't recognize the sender):

Subject: Fw: ALERT, ALERT HUGE VIRUS COMING !!! PLEASE READ & FORWARD !

Please be advised.......I just received this from a friend and checked it out. It is for real.
I strongly recommend that you pass this along to your friends and those on your e-mail list.
Doug

I checked with Norton Anti-Virus, and they are gearing up for this virus!
I checked Snopes , and it is for real!!
Get this E-mail message sent around to your contacts ASAP.
PLEASE FORWARD THIS WARNING AMONG FRIENDS, FAMILY AND CONTACTS!
You should be alert during the next few days. Do not open any message
with an attachment entitled 'POSTCARD FROM HALLMARK,' regardless of who sent
it to you. It is a virus which opens A POSTCARD IMAGE, which 'burns' the
whole hard disc C of your computer. This virus will be received from someone
who has your e-mail address in his/her contact list. This is the reason
why you need to send this e-mail to all your contacts It is better to receive
this message 25 times than to receive the virus and open it.
If you receive a mail called' POSTCARD,' even though sent to you by a
friend, do not open it! Shut down your computer immediately.
This is the worst virus announced by CNN. It has been classified by
Microsoft as the most destructive virus ever. This virus was discovered by
McAfee yesterday, and there is no repair yet for this kind of virus. This
virus simply destroys the Zero Sector of the Hard Disc, where the vital
information is kept.
COPY THIS E-MAIL, AND SEND IT TO YOUR FRIENDS. REMEMBER: IF YOU SEND IT
TO THEM, YOU WILL BENEFIT ALL OF US


I really want to see the code of this virus that "burns" the hard disk. It sounds awesome.