Posted: January 5th, 2010 | Author: Huyen Tue Dao | Filed under: Development | Tags: amdahl's law, formula, performance, speedup | No Comments »
Okay, I promise I will try very hard not to bore you in the next few hundred words. But basically I just want to present a way of determining how much faster a system will be if you speedup one (or more) or its components.
Say that you have an enhancement that can be made to speedup some part of an application.
And say that you know how much runtime you can save with the enhancement.
And say that you know what fraction of the total runtime that part of the application takes up.
Then you can determine how much you will speedup the application as a whole by making that enhancement.
Why is this valuable?
You might be in a situation where you have to justify time and effort spent (and fancy formulas help to dazzle the crowd).
You might have two different enhancements or changes that could be made but only have time to do one. Which should you choose?
You might just want to know how badass your idea really is.
So, I present to you Amdahl’s Law:




Formulas borrowed lovingly from Hennessy + Patterson’s Computer Architecture: A Quantitative Approach
You could use this formula for any other performance metric. For example, if you were more concerned with memory consumption, the formulas still hold: just replace “runtime” with “memory use” and “speedup” with “memory reduction.”
Hope you find this helpful someday. I’ll try to keep so many equations out of the next post.
Posted: January 3rd, 2010 | Author: Huyen Tue Dao | Filed under: Technology | Tags: counter, hard disk, main memory, mom, refrigerator | 5 Comments »
I guess it’s my bad for using the word “memory” interchangeably for main memory and hard disk space to my parents. They’re pretty computer enthusiastic but don’t quite know all the ins and outs yet. I built them a new box with plenty of RAM this time around since that had been the big issue before, dragging the old box down. I assured them that “You have plenty of memory.” So fast forward a few months and I get a call saying that the “Computer says it’s running out of memory. You said we had plenty of memory!” Yikes.
I tried to find a way to explain the problem without getting all bogged down in tech details, so I tried to explain it like this:
Mom, your computer has two kinds of memory. One is called its “main memory,” and the other is called the “hard drive.” They both store information, but they’re pretty different. Think of your main memory as your kitchen counter. When you’re cooking you do your actual work there. You can put some stuff on the counter but not a lot, but when you need stuff on hand to grab quickly you put it there. Also in general you can’t leave stuff on your counter forever. You only use your kitchen counter when you’re cooking. Think of the hard drive as your refrigerator. Its for long term storage. You can put a lot more stuff in there, but it takes a little more time to go over, open the door, look for what you need (especially say if it’s hiding behind the milk), and bring it over to the counter where you’re actually doing stuff.

Your main memory.
Omelet fixings not included.

Your hard disk.
Need to defrag the eggs.
So when we upgraded your “main memory” we were giving you a bigger counter so you’d have more space to fit more stuff. That helps a lot if you’re making something really complicated or just doing a lot of cooking. But I forgot that you like to take a lot of photographs. Think of it as how you like to grow lots of your own veggies at home which you then store in the fridge. So after putting so many homegrown tomatoes in the fridge you basically ran out of fridge space (ran out of “hard drive” space). So what we need to do is get you a bigger refrigerator or at least an extra, maybe smaller one to hold just your veggies or drinks or something like that.
My mom really seemed to like and understand that pretty well. I had originally gone with long-term vs. short-term memory, but our family is all about the food-service business so I thought maybe going-with-what-you-know would help.
I suppose if you want to get really into it you could compare a cutting board to a cache, but maybe that’s a little too nerdy. O.o
I hope if you ever need ‘xplain to your mom or another loved one that this helps a little.
Now excuse me, I think I might have put that zip file I need behind the milk.
Posted: December 10th, 2009 | Author: Huyen Tue Dao | Filed under: Development | Tags: git, gui, mac | 4 Comments »
I know that maybe for the sake of personal robustness (Insert obligatory bad joke here) that I should be training myself to git via command line and learn the ins and outs of this distribute-ed version control. But I have to admit I love guis. I especially love native-application-type guis on Mac OS X. Knowing this, a somewhat reputable source recommended GitX and Gity.

GitX is very similar to gitk, the Unix-based repository browser that comes as part of the git package. Being an open source project, it has that nice price tag of $0. It has a nice browser with a cute timeline-type representation of the repository history (just like gitk) as well as a flexible interface for staging commits. The diff functionality is clear and easy. But that’s pretty much it. You have to already have a repository setup locally, and you can only commit. No pushes, pulls. You can branch but no tags.

Gity by Mac Endeavor is less a repository browser and more of a straight-up gui for most git functionality. Branches, tags, and remotes are listed on the left hand side, and the main page basically lists files in the currently repository. There are toggles for untracked files, modified files, and staged files. Commits are a simple dialog. The implementation of these features feels lacking compared to that of GitX. However, Gity rocks when it comes to all the functionality that GitX omits. You can clone repositories, create new remotes, fetch, push, pull, branch, tag, configure git, and other advanced functionality that flies over the head of this n00b. UPDATE Thanks to Aaron @ Mac Endeavor for giving some heads up in the comments on updates to Gity history and diff functionality.
Is one better than the other? In my opinion, nope. I use Gitx daily. I use Gity every now and again. Gitx does what little it does very well. Gity is loaded with features. GitX is free. Gity is $18 (after a 20 repo refresh trial). Do I think that Gity is worth $18? Eh. I would pay $18 if GitX and Gity merged to have GitX’s interface with all of Gity’s extra functionality. THAT would be epic, and I know people before me have said the same. On a related note, anyone else notice how strangely similar their logos are? Hm… *speculate, speculate*
But fanciful, wistful fantasies of applications-not-yet-written aside, if you do end up getting both GitX and Gity, you’ll be in good shape to getting going with your git-ting.
Posted: November 13th, 2009 | Author: Huyen Tue Dao | Filed under: Development | Tags: 360flex, conference, speaking | No Comments »
Just got my welcome letter today as a speaker at 360|Flex! I will be again presenting Greenthreading as I did at CFUnited, but I will be expanding to include some more material and more examples and address questions that came up during my first session.
If anyone has any suggestions or questions still or ideas of whatever further extensions or clarifications they would like to see, please feel free to email me and hope to see you in San Jose!
Posted: November 6th, 2009 | Author: Huyen Tue Dao | Filed under: Development | Tags: actionscript, compiling, flex, optimization, performance | 2 Comments »
Alright, so I saw this insideria.com article by Tyler Larson about conditionally compiling for cleaner Actionscript when it came out and figured that it would be a good idea for peeling out some performance. And Procrastee McProcrastinator (that’s me) didn’t get a chance to try any kind of pruning yet.
Then tonight as I’m tidying up some code for my side project I see this tweet by Ben Clinkinbeard noting that adding a trace statement increased a loop’s runtime by 1 second. So following Larson’s article with a little help from flexexamples.com for setting up a flex-config.xml file, I set conditional compiling for every single trace statement and then compiled a new release build.
Wow. Just wow. We’re talking seconds shaved off loading batches of images. And I’m frequently loading these small batches of images so the additional time was just piling up.
I feel incredibly duh-I-should-have-known-that-I-am-such-a-noob.
But hey, live and learn, right? And I apologize to folks following me on Twitter for the spam and gratuitous face-palming.
Update: Dave Rosenfeld informed me via Twitter that trace actually initiates some disk I/O. No wonder.