Performance Gains in Jython 2.5.2

Jython, the java implementation of the python language, has long been slower than it's cpython counterpart.  I've personally seen some simple benchmarks from years past such as this, where jython would actually run 3-10 times slower.  Benchmarks between the two implementations can be tricky, as I'm sure there are are some things one does better than the other depending on each developer's design decisions.  jython 2.5.2 was released this last March and has noted several performance improvements on its updated features.

I wanted to do a quick test just to compare the latest performance improvements implemented by jython's development team.  I had a simple ray tracer lying around (link) from when I was learning python at my current employer.  This is a very simple script that renders the scene at 512x512 resolution in about half a minute.  The scene has no acceleration structures to speak of and no texturing, so it's just a series of brute force calculations and pretty much zero to cache compared to a more complex scene.

Scene consisting of a procedurally-checkered sphere, a reflective sphere, and a Lambertian plane lit from above by a point light.  

Graphing

I repeatedly ran the script using each implementation and averaged each result.  I reran the cpython implementation a couple more times to make sure a jump for one run was a fluke.  Apparently it was.

• cpython 2.7.1 - 34s, 38s, 33s, 32s, 33s
• jython 2.5.1 - 37s, 37s, 36s
• jython 2.5.2 - 26s, 27s, 26s

Just a few thoughts and comments:

• jython 2.5.2 seems to definitely have some noticeable performance increases over 2.5.1
• jython may now be faster than cpython in certain situations (like the script above)
• jvm startup time was not taken into account as timing was done inside python
• for both jythons, JIT seemed to consistently kick in at around 10% of the run (I'm assuming it was JIT), where the script started to run faster

Although I use cpython for pretty much all my work, I'm pretty happy with the results and am excited to see jython make a bit a progess.  While one implementation may be faster than another in different circumstances, I think this shows jython's performance is at least similar to cpython for certain tasks.  Maybe future decisions to use one over the other will now depend on which libraries are more appropriate for a given project.  Of course, that may also change as I see importing cmodules on the jython TODO list.

update: 

In response to a handful of commenters, they asked for pypy to be included with the test.  I downloaded the latest x86 build for my system and reran the script three times--all three runs completing in eleven seconds.

Someone also mentioned if I had tried the new Java 7 build, which is the answer is yes.  I orginally downloaded java 7 to compare jython 2.5.2 against the newer version of java (which led to this benchmark).  I've heard a couple of features in particular slated for Java 7 would provide huge performance gains over Java 6 for the JVM scripting languages.  After running the two JVMs, however, I couldn't see much of a difference in performance.  Because of the newness of Java 7, I'm going to do some more investigating to make sure I had everything setup correctly to take advantage of these improvements.


Graphing

My thoughts on Ubuntu Unity

Over the weekend, I made the painful mistake of upgrading to Natty Narwhal 11.04, the newest release of Ubuntu Linux.  I was previously running 10.04 and realized I was stuck with Qt 4.6 and I desperately needed a feature in 4.7.  After starting the upgrade process, I realized I actually had missed the last upgrade 10.10, which was required before upgrading to 11.04.  I installed that and realized it contained Qt 4.7.  I could have stopped there and be content, but I didn't.

I love Ubuntu for various reasons but mostly for its usability.  I can do okay on other distributions, but as my life gets busier and busier, I need my operating system to "just work".  Sometimes I'm tempted to upgrade my distribution instantly when a new one comes out, but I usually regret it getting bit by stupid bugs and such.  Jumping to Natty Narwhal 11.04 was no different.  I had read several negative reviews on Natty Narwhal and wanted desperately to believe they were wrong, but I sadly had to change back to the classic interface.  And it only took me a few days.

Here are a few of the hurdles I hit--all of which having to do with Ubuntu's new Unity system.

1. Restarting my machine, I couldn't log into X.  I found that my nvidia driver module wasn't being built for the upgraded kernel.  Somehow installing a package and skipping a seemingly-required module is totally okay.  To me, though, it continually hung on the Ubunutu "five-dot" splash screen.  I had to actually go get the linux-headers package for my kernel and then reinstall the nvidia-current package, which rebuilt the module correctly.  Couldn't the former be a dependency of the latter?  
2. Unity's "taskbar" is a little buggy.  I'm not sure the rules for it staying out or autohiding, but it certainly wasn't consistent
3. I don't consider myself a power user, but I like to have widgets like workspace tracking and the CPU histogram
4. I missed all my icons at the top of the screen.  I open multiple terminals all the time for programming.  With the Unity taskbar, when I click on the terminal icon, it will either create one terminal, or take me to the workspace where my terminal is already opened.  I just want a new terminal window
5. It's hard seeing what's on the screen without the traditional taskbar.  Windows got buried under each other and I didn't know where they were (the taskbar in Unity doesn't help, while the more classic taskbar shows me exactly what's running on this workspace).  Also, how do I change the number of workspaces?  I had ten--and I used every one--and now I have four
6. This is a minor complaint that I can get used to, but Unity uses the "Universal Menubar" style ala Mac OS X, where the focused application has it's menubar at the top of the screen.  This isn't necessarily bad, but it hides all the menus until you mouse over the bar.  Why?  
7. I actually had some random bugs including loading windows that appeared with no border and certain programs not receiving mouse input after I returned from a different workspace

To me Unity was like Knight and Day with Tom Cruise.  I sat down to watch it and I really, really wanted to like it despite all the negative reviews.  But it just didn't work.  Like this mediocre movie, it wasn't a horrible premise (besides a cliche hacker and a mystical power source the size of a AA battery), but it just wasn't executed correctly.  I believe most of these issues are fixable, but I'm afraid this new desktop has left a bad taste in a lot of people's mouths.  

Integrating Sunflow

I've been playing around with some utilities for moving lights around a scene and rendering it in Sunflow for years.  I've done so much rewriting just to destroy it over and over again, I decided to just take much smaller bites and try doing something very tiny with the program.

• import a PLY object (buggy)
• add an attentuated spotlight
• camera controls (incomplete)
• adjust basic global illumination

My silly toy

no bounces

Using jQuery UI's date picker on all django forms

After getting over the initial learning curves of django's forms, I've begun to really appreciate the level of customizability the developers have incorporated into the API.  By default, when sending a model to a form, any DateField members are converted to form DateField instances, which translates to a simple textfield.  This isn't very attractive and quickly leads to formatting complaints from users (and supervisors). There's another widget django provides for picking dates--three comboboxes for month, date, and year--but it's not a very elegant solution.  I thought it would be nice if, by default, all my forms could use jQuery UI's datepicker.  Here's what I did.

First, after some searching online, it seemed several people have experienced similar issues.  I happened to run across this answer on stackoverflow for customizing widgets for all forms.

Here's my final code.



def make_custom_datefield(f):
    formfield = f.formfield()
    if isinstance(f, models.DateField):
        formfield.widget.format = '%m/%d/%Y'
        formfield.widget.attrs.update({'class':'datePicker', 'readonly':'true'})
    return formfield



class ProjectForm(ModelForm):
    formfield_callback = make_custom_datefield
    class Meta:
        model = Project




First, on ProjectForm I specify a custom callback function for handling form fields.  This is actually really nice as I can apply this code to any form I want instead of marking individual fields for a form or applying the entire fix to every single model.

In make_custom_datefield I do a quick check to see if it's a model DateField instance.  If it is, I do some modifying.  First, I change the format of the widget so incoming data from the model match jQuery's format.  It might be possible to modify jQuery to match Django, but whatever.  Then I add on two custom attributes to the widget.  Both of these directly map to html attributes of the input tag.

<input class="datePicker" readonly="true" type="text" id="id_dateDue" />

The datePicker class is important so I can mark this input as a jQuery calendar in the browser.  I also mark it as readonly so users can't modify the date with bad formats.  Marking the input as read-only is a double-edged sword as it also prevents users from quickly entering dates months or years away.

Once that is working, I just need to add some code to my page that will mark all datePicker instances in javascript as being datepicker widgets.


// on page load

$(function() {
$( ".datePicker" ).datepicker();
});

And that's it!  I can now make jQuery UI datepickers the default widget on any django form I choose.

PHP vs Python: A followup

I received a lot more commentary for my previous post than I anticipated, so I thought I'd followup with some comments and feedback I received.

PHP not dead, just out of use
First, the title of my previous post included the phrase "dead to me".  I in no way wanted to imply PHP was worthless to anyone and its large community was going away.  I honestly don't care if PHP sticks around forever.  My point is that as templating libraries for the web have gotten so good, much of the code is outside the template and the small benefit of embedding PHP directly into html is much less useful than it used to be.  www.php.net's first description for those who might be new to the language are immediately shown, "PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML."  Within the first sentence they advertise PHP as being html-embeddable.  My point is, big woop.

PHP's gotten boring
Many people have commented on other forums about leaving PHP, because its gotten too boring.  And vice versa, leaving another language like python because it too got old and went back to PHP.  Whatever floats your boat, I guess.  In some ways arguing about the pleasure of programming in PHP over python is like arguing the merits of Spanish over German.  Clearly, German is superior.

People tend to have relatively strong opinions over rather mundane things ranging from favorite foods to their preferred brand of socks.  Programmers similarly can have very strong opinions over their languages of choice when sometimes it's their our to express themselves.  Reading blogs comparing lines of python to lines of ruby tend to put me to sleep.  Some comments on this subject included the ugliness of php or python.  Ugliness, of course, is a very subjective word.

Years ago I encountered a site railing against the java language.  I found most of the author's points, however, to be mostly an issue of taste.  One issue he mentioned was the case-sensitive nature java required/assumed.  This perplexed me seriously as almost every language I've ever used in my life was case sensitive.  Indeed, jumping over to TIOBE, it looks like the top ten languages all have case-sensitive syntax.  To OO developers, this style is often used to easily distinguish between class and object.  Calling java ugly for using a industry standard?  That's like calling a girl ugly because she's not a blonde asian.  My point is what exactly is ugly about python?  To me calling a programming language ugly demonstrates an inability to express one's possibly valid thoughts on a language.  For example, some perl I might considered "ugly" for its compact, symbol-based syntax and parameter passing.  Some find python ugly simply for lacking the C-style angle brackets between blocks--are they by contract considered beautiful?  One might call java ugly for its extreme use of compositing just do simple file I/O.  Or are these people literally calling some language visually displeasing?

So beautiful...

PHP's Community
One of PHP's biggest strengths is its availability across a large range of hosting providers.  PHP currently is the standard web language any hosting service must provide.  Hosts providing alternatives such as python and ruby-on-rails usually are a little harder to come by, which is a boon for PHP.  One commenter strongly disagreed with my statement of the python community's size compared to php.  The community can mean different things, so I'll admit it my mistake.  Again, looking at the TIOBE data, PHP is shown to be more popular than python (though the latter looks to overtake it next year).  Or you can simply google "php community" and see it garners more than 77 times the hits as "python community".  Maybe python programmers are anti-social...

Long live templating engines!
Concluding with my previous post's title, templating engines have replaced my "need" of PHP.  PHP isn't horrible by any means, but with capable templating engines in so many languages, anyone can just program in _insert_favorite_language_here_.  In this case, PHP is just another scripting language.  I thought about porting blocks of PHP code to python for readers to compare, but after a brief perusal I found the endeavor totally pointless considering the relatively little changes I'd make between them.  So instead of ending with a quip, I'll end with a question: Supposing a script-savvy developer was entering web development, what are some motivations for using PHP I haven't mentioned?

php to python: Why PHP is now dead to me

PHP started in 1995 and was a well-known web language by the time I was getting into web development around 2001.  At that time I had just picked up perl--yes, perl, which at the time seemed like the end-all, be-all sexiest language ever.  The only thing I liked about PHP, which I admit was a very big draw was the seemless fusion of content and code.  With PHP's delimiters, one could easily blend between the content and wiring.  Almost ten years later, though, PHP is starting to show serious age to the point of being a deprecated tool in the toolbox (like no one making Phillips screws anymore). 

PHP as a web language
My first grudge against PHP is it's not a very generic language.  People have successfully written non-web-based PHP applications, but this seems to be more of a PHP programmer, who doesn't want to learn a more robust language. After a brief scan of various PHP support sites, PHP development outside the realm of web development is basically negligible.  I see no reason, in fact, besides some amazing library I might not be aware of, for me to use PHP for a non-web-based application. 

PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML.  -http://www.php.net/

The syntax is ugly, in my opinion: requred semi-colons, arrows instead of periods to reference data, global functions to manage things like arrays instead of a more object-oriented approach, etc.  After several iterations of the language, features seem tacked on to the early implementations.  With python being faster and providing a larger development community, what motivates me to use PHP? 


The MVC architecture
The MVC architecture is a design philosophy of separating the application into three sections: the models, which manage the data of the application; the views, which typically represent the user interface of the application; and the controllers, which handle a lot of the management between the views and models.  While this design can be strictly conceptual to a programmer separating out functionality, various frameworks like Qt and CodeIgniter strictly separate these entities.  Here's where I believe php has lost it's magic.

The main allure of PHP that stole a lot of perl's magic was putting the controller elements doing the processing directly into the html.  Instead of managing large perl files mixed with html, people could make a mostly html-based file with a little PHP, which was much cleaner to read.  In that sense, all the view implementation was usually separated from the model and controller.  This seemed great at the time, but as MVC has gotten more prevalent, more and more PHP frameworks remove model/controller components from the html leaving small bits and pieces in its place.  In my experience, and what seems to be the practice now in PHP, large controllers and models are created completely separate to the actual html.  This creates a more coherent architecture, but it raises the question: now that we've moved so much PHP code away from html, why are we still using PHP?

The rise of templates
Templating libraries have been around for many, many years-even before PHP was popular.  However, since some programming language had to drive the application anyway, I believe, there was no reason to use one if one had to do his/her coding in C/C++ or perl still.  Now, however, many new languages have emerged such as ruby and python that provide a very small and more robust scripting experience.  Because they are so general purpose, many more examples exist outside of web development.  This is important as web applications have continually provided more and more functionality than just serving up semi-static web pages.  The little bits of php code that was once in my html files are now easily replaced with some templating library like mako or genshi, and I can program in a more general-purpose language, whose techniques will apply to non-web-development tasks as well.  Again, now that PHP has been moved outside of html, why should I use it over python or ruby? 

Things I'll miss
Alas, PHP, I hardly knew thee.  One thing I'll slightly miss, though, is the startup time in PHP.  Almost every apache configuration on Linux typically comes with PHP configured.  After opening up a .php file and typing a few lines, I can access the file directly in my web browser and I'm immediately seeing the results.  With python, I have to do a little bit more typically to get things running via apache.  This requires setting up a cgi-bin, creating a proper script alias, etc.  Newer python frameworks like web.py and turbogears now come with a mini-web-server included, however, so I can hold off on configurations until I'm farther in to production.

I'll also miss PHP's documentation, which I believe is generally more accessible than python's.  Many of PHP's functions get an entire page dedicated to them like explode().  The page features the basics you'd expect from an API doc--parameters, description, and return value--but includes a huge swath of examples of how to use the function.  It's like an entire programming cookbook dedicated to that function.  I find a lot of python docs to be a little too wordy (ex. datetime and difficult to browse to a particular function--especially if I'm searching by functionality and not name.  If I'm unfamiliar with a language, I'd like to know what functions are available for a given class before treading through each and every description.  The function name should typically provide sufficient description to investigate it further.  Anyway, the PHP wiki/comment style of documentation is something I hope more languages adopt.  Wikis are already prevalent on many projects, but it seems people are much more willing to contribute through a brief comment box instead of stepping into an entire editing mode.  Is it fear?  Laziness?  Regardless, it seems more accessible to contribute something beneficial to the doc.

Anyway, PHP.  Thanks for everything.  It was fun while it lasted.

Using Redbean with Code Igniter 1.7.3

I started playing around with codeigniter for a quick project, and wanted a simple ORM for manipulating databases quickly. After looking briefly at RedbeanPHP, I decided to give it a spin. Boris Strahija had actually shown how to do it last year in the forums, but I just wanted to post my files for reference. This assumes the database.php file in your config dir is already pointing to a valid database. I was using mysql.

1. Download RedbeanPHP and drop the two files (._rb.php and rb.php) in system/application/libraries
2. Create a library class called Redbean.php with the contents shown below, and drop it in the same directory
3. Use it in your controller

Redbean.php

ci =& get_instance();

// Include database configuration
include(APPPATH.'/config/database.php');

// Include required files
include(APPPATH.'/libraries/rb.php');

// Database data
$hostname     = $db[$active_group]['hostname'];
$username     = $db[$active_group]['username'];
$password     = $db[$active_group]['password'];
$database     = $db[$active_group]['database'];

// Create RedBean instance
$toolbox = RedBean_Setup::kickstartDev('mysql:host='.$hostname.';dbname='.$database, $username, $password);
$this->ci->rb = $toolbox->getRedBean(); 
    }
}

Using it somewhere in your controller

// example code of creating a 'post' table
$post = $this->rb->dispense("post");
$post->title = 'My first post from CodeIgniter';
$post->body ='Lorem ipsum dolor sit amet, consectetur adipisicing elit....';
$post->created = time();
$id = $this->rb->store($post); 

After running this controller, you should see a 'post' table created. Done!

What you should see in phpMyAdmin