Edward Kandrot’s Programming Blog

I tried something new.  I was curious as to why the times varied so much, so I installed VMWare on my MacPro and ran the previously mentioned code under a few OSes.  I have Ubuntu 64 bit installed on a separate HD for my Mac, so I installed one under VMWare to figure out how much the VM software would skew the other results.  Looks like not by much.

MacPro, Ubuntu 64, direct boot -> 3.7 seconds
MacPro, Ubuntu 64, VMWare -> 3.9 seconds

With this out of the way, I can tell that the numbers I get from under VMWare would match up pretty closely to what I would see if I installed the OSes/Erlang directly.  Here is what I found under the VMs:

MacPro, Windows XP 32bit -> 6.9 seconds
MacPro, Ubuntu 32 -> 18.9 seconds

What does this tell me?  That the test I was using for Erlang speed is heavily based on the underlying bit-ness.  Erlang on a 64 bit system is faster than the 32 bit version when doing large number arithmetic.  And the AMD 4600+ is half the speed of the Xeon chip in the MacPro.

It looks like this is a win for 64 bit.  These new results help explain something else I had seen last week - the speeds of F# and Haskell on the same problem.  It took 32 seconds under Haskell and minutes under F# on a 32 bit machine to do the same factoring.  I’m guessing that they would be faster on a 64 bit version, though I know that F# is only 32 bit right now, but I hope it becomes 64 bit soon!

-Edward

 The first piece of code that I wrote in Erlang was to factor numbers.  I thought it would be a good test to learn the basics of Erlang (very basics).  I have appended the code to this post.  I am not sure if it the fastest way to factor a number (vs building up the list, but it would have to pass an accumulator around), I will have to investigate that in the future, but it served its purpose for now. 

I then used this code to test which machines and implementations of Erlang were the fastest and got some interesting results.  The code factored 380312393432894324523423103, which I discovered by typing in random numbers to factor.  It has a large factor, 9517107199440611, which makes it a reasonable benchmark for a simple test.  Here are my results:

AMD 64, 4600+, Windows XP -> 15.4 seconds
MacPro, 2.66 Xeon, Linux -> 3.7 seconds
MacPro, 2.66 Xeon, MacOSX -> 7.0 seconds
MacPro, 2.66 Xeon, Vista64 -> 7.3 seconds

I only have one OS on the AMD, but it would be interesting to see if Linux is 2x faster, as it was on the MacPro.  I was surprised that the Xeon chipset in the MacPro was so much faster than the AMD64, but I guess they are more than a year apart in age.

-Edward

fac(N) -> fac(N,2).
fac(N, F) when F*F > N -> [N];
fac(N, F) when N rem F =:= 0 -> [F | fac(N div F, F)];
fac(N, 2) -> fac( N, 3 );
fac(N, F) -> fac(N, F+2).

If you go to the link on ray tracing, you can see some of the images that I did. Simple stuff, but they were fun and interesting to do. The interesting part for me was that all of the ones that I did, I did to teach myself a few new functional programming languages: Erlang, F#, and Haskell.

This is kind of linked to my post about UI. The thing I liked about learning these functional languages is that made focusing on the problem at hand the point of coding, rather than fighting the language. Don’t get me wrong, I’ve used C/C++ for many, many years and am an expert at them. But if I want to whip out a demo of a new idea, or learn ray tracing, I like to prototype in a higher level language. That used to be Smalltalk back in the early 90s, then Python in the 2000s, but now I’ve switched to these functional ones.

When an idea strikes, I just want to sit down, type away, and make progress towards my goal of seeing my idea on the screen. The problem with C/C++ is that if one doesn’t already have the framework in place for the idea, a lot of time is spent on memory management code, allocating objects, defining APIs, etc. That kind of stuff is great for a performance person, since it gives me a lot of axises along which to tweak code for performance, therefore getting me a lot of performance jobs, but it isn’t so great when I have a weekend and want to explore ideas.

Just like with a bad UI, one can get things done if one has done it before, but with a good UI and a good programming language, getting stuff done for the first time is a lot of fun!

-Edward

I updated my Arcane Future site today, so this blog will now be linked to it!  I am using DreamWeaver to create and maintain my website.  The program looks like it can do a lot of things, but the interface makes it really hard for a beginner to figure out how to make it do those things.  I even watched some of the videos at Adobe.com, but most assume that one has created a website previously.  Then there is this blog software…  it removes all of my carriage returns putting everything in one long paragraph.  I found a way to trick it into doing what I want some of the time… 

My question is:  why does most software make the user struggle to get things done?  I only use a limited subset of software out there, mostly for programming, math, spreadsheets, and games.  And in every case, the struggle isn’t with the concepts of the application, but with the User Interface. 

I am not a UI person, my passion is for code performance.  But at some point, doesn’t UI factor into this?  If it takes a person 2x to 10x longer to get to the part where they are being creative, doesn’t that overwhelm the time I can gain by making the program 2x to 10x faster? 

Which is worse:  finding a program that does what you want, but is unusable because the UI totally obscures the  functionality, or finding a program that does what you want but it takes hours to run? 

-Edward 

I had been obsessed with Ray Tracing the past week-ish.  I wrote a basic one in Erlang, so I could learn more about this interesting language.  It was kind of slow, it took 50 seconds to generate this image:

   Then I picked up a book on F# last Sunday and started over.  F# is kind of interesting, and definitely generates much faster code.  I was able to get many more features into my F# version.  See these images:

 I will post more about my experiences with these languages as well as more about the images.  Mostly, I am testing to see if the blog software works. It doesn’t.

-Edward

This is my first post to my Arcane programming blog. My plan is to fill this with my experiences while programming as well as share some of my past experiences. I hope you enjoy it.  -Edward