About

Print Friendly, PDF & Email

My name is AJ Guillon, and you can find a short introductory blog about myself here.  I am currently working as a consultant, helping companies with multi-core and OpenCL development.  I also volunteer to help open source projects that might need my expertise.

Affiliations

  • Khronos member.  I am a member of Khronos and helping to shape the future of heterogeneous computing through OpenCL, alongside other members.

Skills:

  • C++11 expert.  There are some dark and dusty corners of C++ which are unfamiliar to me, but I have extensive C++ experience.  I can do template metaprogramming, library design, and pretty much anything you ask me to.
  • Linux expert.  I have been using Linux exclusively since 1999, and although I have not hacked on the kernel, I am familiar with advanced OS design (thanks to advanced university courses).  I can do system administration, though I prefer not to.
  • OpenCL expert.  I started with OpenCL in 2008!  I know OpenCL very well, and I have worked on many interesting projects.
  • GPU programming.  I’ve been doing GPU programming since 2008.
  • Algorithm design.  I love algorithms, and in particular I love parallelizing sequential algorithms, though there might be limits to this (P = NC?).  I also really enjoy tuning algorithms to hardware, which is often required for top-performance on a GPU.
  • Software engineering.  I have designed library APIs that people actually like, and I  know when to use design patterns (and when not to).  I am experienced in project management, and have been greatly  influenced by how open source projects get things done.
  • Mathematics.  I am capable of thinking mathematically, and apply discrete mathematics and statistics to problems frequently.  I am a computer scientist, which means I think in a very discrete way, and shun the real number system.

Work Habits:

  • Standard Compliance.  I adhere strictly to published standards, except in rare cases where non-compliance can be justified (and even then, I isolate that piece of code).
  • Documentation.  I actually write documentation, and although it can take time, I do enjoy the final result.
  • Problem Research.   If you give me a problem, the first thing I do is read everything I can about it, and what has been tried before.  This ultimately saves time and results in high-quality work.
  • Paper Design.  I do almost all of my software design on paper.  I won’t write much code until I have a solid design in mind, and have sketched out a number of alternatives.

Projects:

  • YetiSim.  A discrete-event simulator, and my first multi-core application.  I intend to redesign it.

Education:

  • B.Sc University of Toronto