I just approved and then changed my mind and un-approved a comment. The comment was a fair, if somewhat harsh, criticism of the Pixel Bender Toolkit. I originally decided to approve it because it was one person’s opinion and a response to something I wrote, and I don’t mind answering criticisms (even when they are worded less-than-delicately). However, I changed my mind because the writer decided not to include a valid name or e-mail to respond to.
So, that will be a rule I’m going to hold on to moving forward. If you want to post your honest opinion to something I write, I will always try to honor you and will post it; and respond. As long as your comments are:
not overt flame-bait
do not swear
are signed with your real name (or handle) AND e-mail address (which is not published, but lets me know that you are willing to put your name to something)
Hopefully, this should not strike anyone as draconian.
JJ, if you want to re-post with your real name and e-mail address, I will gladly approve your comment.
Tomorrow morning, I’ll be speaking with Paul Steinberg of Intel and Tom Murphy of Contra Costa college about the criticality of understanding parallel programming techniques for industry.
In my previous role on the Adobe Image Foundation, it was an obvious requirement for our hiring candidates. We were building tools for a insanely parallel problem, image and video processing. Now that I’m working on a new product, it would maybe seem that it would not be as important. In fact, our threading models are even more complicated than in my previous group. My expectations around threading knowledge for incoming candidates are just as high.
Even the most modest mobile hardware is going (or has gone) parallel. In addition, the expectations from a user perspective around interactivity with their applications is never higher. A laggy touch interface is death to an application (or a platform). Going to get coffee while your image renders on a desktop is a thing of the past. User’s expectations of the software we write is higher than ever and it is nearly impossible to get this interactivity without taking advantage of multi-threading on today’s multi-core processors.
The tools continue to improve, but the threading models continue to evolve. A fundamental understanding of multi-threading is critical for anyone moving into Software Engineering or looking to stay current in their field.
I always enjoy talking with Paul and Tom, and expect that we’ll have a lively conversation.
If you are planning on attending the AMD Fusion Developer Summit in Bellevue, WA in June, come see me talk about Pixel Bender (probably for the last time!) with Bob Archer. Here is the description of the session:
Pixel Bender is a domain-specific image processing language created by the Adobe Image Foundation, and includes a runtime designed to work well across heterogeneous hardware, scaling efficiently for multiple cores. This runtime currently ships in a number of Adobe’s flagship products. Bob Archer, Technical Lead, and Kevin Goldsmith, Engineering Manager, will talk about the design of the language, compilers, and runtime. They will also discuss how the Adobe system can incorporate complimentary technologies like OpenCL and can scale to accommodate new hardware paradigms like the AMD Fusion processors.
For the past several years, I’ve been working on leveraging high-performance computing techniques for high-throughput data intensive processing on desktop computers for stuff like image and video processing. Its been fun tracking what the multi-processing end of HPC has been doing, where the top 100 super-computer list has been very competitive and very active. Countries, IHVs and universities vie for who can generate more teraflops; spending millions and millions of dollars on the cooling plants alone for their dedicated data centers. These super computers exist to solve the BIG PROBLEMS of computing, and aren’t really useful beyond that.
At the same time, I’ve been following the public computing clouds like Amazon’s EC2, Google’s App Engine and Rack Space’s Public Cloud. These have been interesting for providing compute on the other end of the spectrum, occasional compute tasks, or higher average workloads with the occasional spike capability (like web apps). The public clouds are made up of thousands of servers and certainly rival or best the super computers in numbers of cores and raw compute power, but they exist for a different purpose.
Stowe tells El Reg that during December last year, Cycle Computing set up increasingly large clusters on behalf of customers to start testing the limits. First, it did a 2,000-core cluster in early December, and then a 4,096-core cluster in late December. The 10,000-core cluster that Cycle Computing set up and ran for eight hours on behalf of Genentech would have ranked at 114 on the Top 500 computing list from last November (the most current ranking), so it was not exactly a toy even if the cluster was ephemeral.
The cost of running this world-class super computer?
Genentech loaded up its code and ran the job for eight hours at a total cost of $8,480, including EC2 compute and S3 storage capacity charges from Amazon and the fee for using the Cycle Computing tools as a service.
Real world HPC is now coming into price points where it is accessible to even small companies or research groups. This seems like a ripe opportunity for companies who can apply HPC-techniques to solve real problems for others, and for tools vendors who can make using these ephemeral clouds easier for companies who want to take advantage of them without having to build up high-end expertise in-house.
I was having a conversation with someone the other day about unit testing. OK, actually I was interviewing someone for a Quality Engineering position on my team. We were talking about the difference between white-box tests that quality engineers write and tests that developers write.
I suggested that good white-box testers test the functionality and the failure cases (the intent of the function) and developers test the code that they’ve written (the function as coded). This then lead me to a new revelation around test-first development methodologies (or possibly reminded me of something I had forgotten).
I have been a proponent of writing tests first, since I first started doing Extreme Programming and read Kent Beck’s original book, Extreme Programming Explained: Embrace Change while working at Bootleg Networks (thanks Carmine for making me do that, by the way). Although admittedly, like many developers, I haven’t always been that rigorous at following that rule.
What I like about writing the tests before the function is that it clarifies my thinking about what the function should do, it alerts me to the corner cases, it gives me reasons to consider if the function is doing too much, and it gives me a way to instantly know if the function works once it is written. Writing the tests first also makes sure that the tests are written at all. Once the function is coded, it sometimes gets tempting to move on to the next bit of coding work with the intention of filling in the tests later.
What I hadn’t considered about writing the tests before the code is that it puts me into a quality mindset without having any bias to the code as I’d written it. I’m divorced from my own blind-spots around my coding. This actually leads me to writing better tests because I have no assumptions about how the code should work or fail. I’m testing the functionality, not the code.
Maybe I’d thought about this before, but I hadn’t really considered that benefit recently until that moment. Now, when I start to get lazy about writing my unit tests before my implementation, I’ll have a better reason to keep up my discipline.
Frequent contributor to the Pixel Bender forums, Royi Avital, has released a new set of After Effects and Photoshop plug-ins written with Pixel Bender under the name Flixel Plugins. The first three are now available on aescripts.com
After many happy and productive years working on Pixel Bender and the Adobe Image Foundation, I’ve decided to take on some new challenges. I’m still at Adobe, but I’m now building a new team and launching a brand new product in the Photoshop family. I can’t say too much yet, but I will have news soon. I’ll still be posting about Pixel Bender stuff here (I’m still a very enthusiastic user!), but for the newest news, you should now also watch the official Pixel Bender blog.
So, in my work e-mail, I get around 200 messages a day. I periodically get myself back down to inbox zero, but if I take a day or two off, I immediately get behind. I recently decided on a new mechanism for sorting my incoming mail. First off, would be to divert any mail not sent directly to me (where my name isn’t on the to or cc line) into a separate folder. This would be the stuff I would get to when I had time. Next would be to divert mail where I’m CC’d into a separate folder (this is the mail I’d read after reading my inbox), all mail with me on the TO line would be left to filter to my inbox. This way, I think I could make sure that I’m not losing the important messages in the noise of the stuff that I don’t need to read (but will when I have time).
Unfortunately, Outlook’s rules don’t let me do this. I can create a rule for messages where my name isn’t on the “To” line, and I can create a rule for messages where my name is on the CC line, but then messages where I’m in the CC line get put into two different folders because they aren’t mutually exclusive. Since the rules in Outlook are more or less fixed, there doesn’t seem to be a way to do what I want here.
Any suggestions (other than get a real mail program)?