[MR] Let’s start off with something easy: What’s with the hat?

You have something against hats? Indiana Jones wore a hat. Maybe I like to wear a hat.

Actually, the hat is shameless self-promotion. One of the bad things about having a small business is that you have little or no advertising budget, so you end up doing silly things like wearing a cowboy hat to any event where a dozen or more potential customers might be.

I actually have a new hat. My old hat never really fit that well, so I found this amazing hat maker, Roy Jackson, and commissioned a new hat. Roy sends you a fitting rig that you put on your head. When you mail the rig back, he makes you a hat.

[MR] Your book Cocoa Programming for Mac OS X has become the quintessential beginners guide to developing on Mac OS X, but your involvement with the platform actually goes back much further than that, to NeXT. Can you tell us a little about the NeXT days, and what your role was?

I was one of the developer trainers, and I was in charge of developing the courses we used.

So, you know how the mother bird regurgitates food her baby birds? Well, I was the mother bird, the food is knowledge, and the baby birds are developers. Only, I didn’t actually puke knowledge of OpenStep and WebObjects in their mouths; I would learn the new technologies from the engineers who were inventing them and then distill those ideas into a form that made learning them easier.

[MR] I heard a rumor recently on the Late Night Cocoa podcast that you were busy working on not just one new Cocoa book, but two. Is there any truth to the rumor, and is there anything you can tell us at this point in time?

The third edition Cocoa Programming for Mac OS X will address Objective-C 2, Xcode 3, and Core Data. I’m working on it now, but don’t expect it to reach bookstores until autumn.

After that, I’m going to write another book, but I haven’t decided what that book will be about. It could be the prequel to the Cocoa book or it could be the sequel. Or perhaps it is time for me to write the self-help book that will bring me fame and fortune.

[MR] Mac OS X ushered in a new era for NeXT developers. What was your feeling about the transition to Apple? Were you enthusiastic, or worried at the time?

I was spoiled. I worked for a company where I got to work on cutting-edge technologies with 350 amazing people. When they said, “You are now part of 9,000 person company.” I panicked and ran.

The cultures clashed a bit, but we ended up with a Unix box that your grandmother would love — something that required the talents at both NeXT and Apple.

[MR] There is no doubt that Apple’s purchase of NeXT presented a lot of opportunities for people loyal to the platform, and you certainly took full advantage of the move by starting up Big Nerd Ranch. For those that don’t know about Big Nerd Ranch, can you give us a quick history?

Big Nerd Ranch, Inc. is taking technical training to the next level.

First, we fixed the things that are obviously wrong with most technical courses: inexperienced instructors and irrelevant materials. Our instructors are the absolute best on the planet, and our materials have been stripped of things that were more sales or novelties than essential techniques.

Second, we took inspiration from monastic retreats. When you come to the Big Nerd Ranch, we eliminate the distractions. It is quiet and your room and food are included. There is nothing to do but learn.

[MR] Big Nerd Ranch began as a Cocoa ‘school’, and you are a prominent member of the Cocoa Developer scene. I remember a few years back a ruckus arising on the cocoa-dev list when you came out hard against the then new Cocoa Bindings. You later retracted much of the criticism, but what is your take on the current state of Cocoa, and where it is headed? Are you enthusiastic about Core Data, for example? Core Animation?

While bindings and Core Data are nice, I think they both could have been better.

In the past, Apple would implement a new technology and use them in their own apps. Once their own engineers had tested and improved the technology, it would be made a public API. These days, Apple uses WWDC to push technologies that they have never actually used in their own applications.

PDFView is an example of a nearly flawless technology. Why? Because it was used in Preview before it was made public. NSTreeController, on the other hand, is crap, and should have been identified as crap before it was dumped upon the adoring developer community.

For a decade, Apple/NeXT has claimed that one could write a word processor by subclassing NSTextView. Then Pages comes along and doesn’t use NSTextView at all. Why would Apple pass up such a great opportunity to test and improve NSTextView?

I am delighted with the state of Cocoa, and it gets better with every release. Think how wonderful Cocoa would be if Apple took every opportunity to eat its own dog food.

[MR] Some of our readers will be interested in Cocoa, but I suspect many more would be interested in some of the other courses run by Big Nerd Ranch. A quick look at the web site shows courses ranging from Core Mac OS X to OpenGL and even Python. Can you discuss a few of the courses that might be of particular interest to scientific developers on the Mac?

Any scientific developer would love our OpenGL class. While still useful to a game programmer, the class focuses on issues related to data visualization. Rocco Bowling, who used to do data visualization work for one of the intelligence agencies, teaches the class. Rocco also wrote Big Bang Chess. His knowledge of the subject is amazing. That class will be offered in Atlanta from April 30 through May 4.

The Core Mac OS X Bootcamp teaches programmers how to take advantage of the plumbing that makes OS X work. It covers topics like multi-threading, network communications, distributed objects, the keychain, and directory services. We also take a long look at tools: gcc, gdb, the linker, subversion, and the performance tools. That class will be offered in Frankfurt, Germany April 16 – 20. It is taught by Mark Dalrymple, the author of Advanced Mac OS X Programming.

Dave Beazley, the author of The Python Essential Reference, teaches our Python Bootcamp in Atlanta May 21 – 25.

If you are doing web development, we offer the best classes in the world on Ruby on Rails, PHP, and Django. (That last one is sort of a cheat: Our Django class is the only one in the world.)

[MR] I also see that Big Nerd Ranch is now intercontinental. Where do you run your courses?

In North America, we teach our classes near Atlanta, Georgia. Atlanta is a great location because it is home to the busiest airport in the world.

In Europe, our classes are taught in a monastery/vineyard near Frankfurt, Germany. Frankfurt is a major hub for all of Europe, and it would be difficult to find a place that better expressed the ideas behind Big Nerd Ranch.

[MR] Finally, what can people who go to a Big Nerd Ranch course expect?

A Buddhist monk should be kind and patient. Can you teach someone to be kind and patient? I don’t think so. So, to train Buddist monks, they create an environment where the students can find kindness and patience themselves.

I can’t make you a great Cocoa programmer, but I can create an environment where you can find the great Cocoa programmer inside yourself.

The post Interview with Aaron Hillegass of Big Nerd Ranch appeared first on MacResearch.org.

OK, let’s start out with the basics. Could you introduce yourselves?

Benoit: I’m a Mathematics postdoc at the University of Toronto, coming from France. I’m working on C*-algebras, and teaching linear algebra. In addition to Eigen, I contribute to a few other free software projects, mostly within KDE. In the past I also contributed to Avogadro and a little bit to Open Babel.

Gael: I’m a French researcher in Computer Graphics currently working at INRIA Bordeaux. In particular, my research interests include real-time rendering and surface representations. My major contribution in the open-source world is by far what I did in Eigen, but I also contributed a bit to vcglib and MeshLab.

What is Eigen?

Benoit and Gael: Eigen is a free C++ template math library mainly focused on vectors, matrices, and linear algebra. It is a self-contained library covering a very broad range of use cases. For example, it covers both dense and sparse objects, and in the dense case, it covers both fixed-size and dynamic-size objects. Moreover it provides linear algebra algorithms, a geometry framework, etc. It has a very nice API for C++ programmers, and it embraces very high performance.

What drove you to create Eigen and Eigen 2?

Benoit: Eigen 1 was a very small project, 2500 LOC and just a few months of development. Its creation in 2006 was driven by the then-simple needs of some KDE and KOffice apps. However it quickly turned out that we had underestimated their needs, and Eigen 1 was insufficient. So in 2007, I started developing Eigen2. The aim was to create the linear algebra library that would satisfy all the needs of KDE and KOffice apps — a goal that, in retrospect, was very ambitious, and will only be reached with Eigen 2.1. After an initial experiment with TVMET‘s code, I decided to restart from scratch in August 2007 and quickly got a working implementation of expression templates. However, this early Eigen 2 was very small. Development speed really picked up when Gael joined in early 2008.

Gael: A bit more than a year ago, I became tired of going back and forth between my own fixed size vector/matrix classes and more generic linear algebra packages. So, I started looking at the other existing solutions without being excited by any of them. Since I have been using KDE for about 9 years, I was really curious to know what the KDE’s folks did in this area. At that time, it was exactly the start of Eigen2 which looked promising but the fact it was based on TVMET puzzled me. Eventually, Benoît had the great idea to restart the development of Eigen2 from scratch, and after one or two months he came up with a very lean design. Moreover his vision and feature plan for Eigen2 exactly matched my own, and being part of the KDE community was exciting too! At the beginning, I naively thought that after one or two months the job would be done! Instead, we started playing with exciting stuff like explicit vectorization, efficient matrix products, sparse matrix, etc.

Many people are familiar with other linear algebra and matrix libraries, including BLAS/LAPACK, Intel’s Math Kernel Library, and Apple’s vecLib framework. Can you explain how Eigen is different, besides being written in C++?

Benoit and Gael:

Giving a fair answer to that question would require a thorough comparison to all existing libraries that is obviously out the scope of this interview. Search for “C++ matrix library” to get an idea. For us, most important criteria include:

• generality,
• performance,
• ease of use,
• license policy.

Even more important is a sort of meta criterion which would glue together all these criteria. Indeed, what’s the point in having a very efficient library but which which cannot handle your specific needs, and/or that you cannot freely use/extend because of the license ? The central difference between Eigen and other libraries reside in this unmatched combination of advantages.

For instance, BLAS/LAPACK are certainly the most popular matrix/linear algebra packages. They can achieve very high performance, but only for relatively large and dense matrices, and through proprietary implementations such as Intel’s MKL or Apple’s vecLib. Goto BLAS too has a restrictive license. API-wise, BLAS/LAPACK are also very painful to use, though that limitation is somewhat overcome by the existence of many high-level wrappers (FLENS, matlab, etc.). In contrast, not only does Eigen provide a feature set to BLAS/LAPACK with better ease of use, but it also seamlessly supports small fixed size matrices, has experimental support for sparse matrices with optional back-ends, and includes other modules such as linear least squares and geometry.

As we said, expression templates bring unmatched expressiveness and performance for basic operations. It is therefore interesting to have a brief look at the few other C++ template libraries which are also based on expression templates. The most popular ones include TVMET, Blitz++, and Boost::uBLAS. However, in contrast to Eigen, none of them provide explicit vectorization nor include linear algebra algorithms. They also perform poorly for both small and large matrix sizes, and suffer from some shortcomings in the way expression templates have been implemented making them hard to use in practice. For example, contrary to Eigen, they do not decide automatically when to use lazy evaluation. Eigen handles most cases automatically while ultimately letting the user override the default behavior. For example, in a chained matrix product A*B*C, Eigen understands that lazy evaluation would be a bad idea so decides to evaluate A*B into a temporary, while Boost::uBLAS requires the user to do that explicitly. Another advantage of Eigen over these other C++ libraries, is that Eigen has still reasonable compilation times: we are very careful about that.

How does performance compare to other alternatives? Do you have some benchmarks?

Gael: Since good performance is one of our top priorities, we indeed regularly run several benchmarks. When speaking about performance it is important to distinguish between small fixed size and larger matrix which require very different kind of optimizations.

About the first category, Eigen includes meta-unrollers and an advanced explicit vectorization mechanism allowing us to generate machine code as good as hand written assembly code. Therefore, in all our benchmarks, we found Eigen outperforms all other libraries, or at least we made sure that was the case by fixing Eigen when needed 😉

For relatively large matrices, we have a comparison of several free and non-free libraries. These results demonstrate that Eigen outperforms all other Free libraries, including ATLAS. Compared to non-Free alternatives like Intel’s MKL and Goto, Eigen is usually faster for both Level-1 (vector-vector) and Level-2 (matrix-vector) equivalent BLAS operations. This is mainly due to expression templates, and a highly optimized matrix-vector product algorithm. However, we acknowledge that matrix-matrix operations are not yet as optimized as their respective BLAS Level-3 routines of MKL and Goto.

Regarding higher-level linear algebra algorithms like LU or Cholesky factorizations, we currently do not provide any block implementations for them. Therefore the equivalent LAPACK routines of vendor tuned implementations scale better for very large matrices. Compared to them, we also lack a support for multi-core computing. But nothing is engraved in stone, and we are confident that all these performance limitations for very large matrices will be overcome in the future, in the short term by adding an optional LAPACK backend to Eigen, and in the longer term, who knows 😉

What projects are using Eigen right now?

Benoit and Gael: Eigen is already used in a wide range of applications. Some of them include:

It is very interesting and motivating to see how many projects already switched, or are going to switched to Eigen, proving Eigen fills a real gap.

How would you write code with Eigen? Could you give me an example, say of multiplying the inverse of matrix A by matrix B?

Benoit: This operation amounts to solving the system AX=B which can be done for example using a LU decomposition. With Eigen you would do:

A.lu().solve(B, &X);

Now, depending on your context, you may prefer using another kind of decomposition. Here, Eigen also allows you to use a QR, LLt, LDLt, or SVD decomposition, each time with the same obvious syntax, for example:

A.svd().solve(B, &X);

If your matrices have small and fixed size, and especially if B is a vector, it can be faster to actually compute the inverse and the product:

A.inverse() * B;

Here is a full example program that you can compile. It works with a 1000×1000 matrix A and a 1000×500 matrix B, with double precision. I get a relative error of the order of 1e-13 which is pretty good. Eigen’s LU does full pivoting which guarantees that it works in all cases, and an user just reported speed to be on par with LAPACK. However, for this kind of large sizes, depending on the CPU cache size, we acknowledge that it would start to be beneficial to have a more cache-friendly implementation, typically working block-wise.

#include <Eigen/LU>// provides LU decomposition
#include <Eigen/Array>// provides random matrices

using namespace Eigen;
int main()
{
  MatrixXd A = MatrixXd::Random(1000, 1000);
  MatrixXd B = MatrixXd::Random(1000, 500);
  MatrixXd X;

  A.lu().solve(B, &X);

  std::cout << "relative error: " << (A*X - B).norm() / B.norm() << std::endl;
}

More examples are given in the API showcase.

Since Eigen is a template library, can you explain the license? Can you use it in proprietary projects?

Benoit: The license is dual LGPL3+/GPL2+. This means it’s LGPL3+, except that GPL2 projects can’t use LGPL3+ libraries so just for them we added the GPL2+ as an alternative. Yes, proprietary closed-source projects may use Eigen, without having to open any of their source code. The LGPL license allows it and we do have several closed-source users.

There used to be a problem with the older LGPL 2.1 and template libraries. Indeed, the phrasing of the LGPL 2.1 was not applicable to the case of C++ template libraries where the code is in header files and is included rather than linked to. Fortunately this issue was fixed in the LGPL3 which now explicitly adresses this issue in Section 3, in addition to having a much more generally applicable phrasing overall. See our Licensing FAQ.

What are some goals of Eigen moving forward? What kind of help do you need? What are some new features we might see in Eigen 2.1?

Benoit and Gael: Our goals for 2.1 are:

Our goals for 2.1 are:

• Finish stabilizing the API (the API guarantee is only partial in 2.0)
• Complete the Sparse module. One goal is to make it good enough for Step in KDE 4.3 and Krita.
• Make sure all dense decompositions are world-class (LU is already good though we have improvements in mind, SVD is being completely rewritten, etc…)
• Make fixed-size specializations of algorithms
• Optimize the case of complex numbers
• Vectorize more operations (e.g., exp() or sin() or log())
• Investigate optionally leveraging new GCC 4.4 hotness: per-function optimization flags

We need a lot of help with all that, more details can be found in our To-do. If new contributors join the team, in the longer term, we could see some new modules covering statistics, fast fourier transform, non linear optimizations, etc.

We also welcome testing, especially on exotic (read: non-GNU or non-x86/x86-64) platforms. All bug reports are much appreciated.

The post Interview: Eigen Matrix Library appeared first on MacResearch.org.

Describe your current position inside Intel and some of the projects you are directly involved with.

At Intel, I manage the Intel® Compilers Technical Support and Consulting team, responsible for all technical support and training for our compiler products. I’ve been with the Intel compiler team since 1996 working as a compiler developer, support engineer and as a manager. We are currently working to help our Intel® Software Development Products for Mac OS X help developers in the marketplace get the best performance.

Can you describe some of the challenges in moving the compilers over to a new platform? Obviously the target CPU is the same, what are some of the technical considerations that must be considered when moving to a new OS?

Our goal is to be command-line, source, object, and debug compatible with the default development environment on the new platform. This means achieving full compatibility with GCC and Xcode* on Mac OS* X in each of these areas. Fortunately, we had a good base from which to start since Linux was already an operating system we supported. Still, there are object code differences, and initially the debug format was different as well. The runtime libraries, particularly our Fortran runtime libraries had to comprehend new OS calls and such. One exciting opportunity was that all the new machines for Apple had at least two cores, so our support for multi-core through our compilers and libraries apply to all the new Apple machines.

Another issue we faced was optimizing for position independent code (PIC).  On Linux, the best performance was with static linking.  Since that wasn’t an option on Mac OS X, we put some effort and creativity into optimizing the PIC code for shared objects.  Now, there is no overhead.

Finally, we had a goal to ensure that our first product on Mac OS X was not de- featured.  We didn’t want it so be a subset of our Linux products.  So we went through and made sure each feature was supported on Mac OS X, including OpenMP, feedback-directed optimizations, IPO and whole program analysis, vectorization and parallelization.

While we are all dependent on compilers, many of us don’t really take the time to appreciate the fact that they are in fact very complicated pieces of software, developed by a wide variety of engineers. Can you give us an idea of what the general workflow is in developing and managing such a product?

They are indeed complicated pieces of software, broken roughly into language processing (front-end), optimization (middle), and code generation (back-end) components. In addition, there are runtime libraries, IDE integration, command-line driver, the Intel Debugger, installation scripts, etc. that make up the complete product. Our team is geographically dispersed around the world, so we have the complexity of managing a world-wide team as well. We follow a fairly rigid process of starting with customer and strategic requirements for the product version, break those into a set of engineering work items, and then schedule that into for the appropriate schedule for our product releases.

The announcement of a switch was made at WWDC 2005. How, in your opinion, had the mood changed about the transition to Intel between WWDC 2005 and WWDC 2006?

At WWDC 2006, it seemed that there was nothing but excitement about the transition. Everyone I met was genuinely enthusiastic about the Intel® processor-based Mac’s, especially for their performance vs. previous generations. People just seemed to want to get their hands on whatever information and software that could help them get their applications transitioned quickly.

Apple’s transition from PPC to Intel happened quite fast (and ahead of the announced schedule). How did the time constraints for Apple’s product delivery affect the schedule for the tools development cycle?

Needless to say, it had a dramatic impact on all of us in the Software group at Intel. It spanned the gamut from elation at the prospect, to exasperation at what it would do to our product plans. We had to manage our efforts to update our other products while scheduling to get the Mac OS products together quickly. Fortunately, the continued development work for our product lines was generally complementary to adding Mac OS X versions. Where it was not, we did make trade-offs to ensure our Apple support was strong and timely. Now, all work going forward includes benefits for Apple developers.

With a switch to a new OS, there exists a need for expertise with that OS to develop products for it. Does Intel now maintain a group of Mac OS X experts in house? How closely does the compiler group work with various groups at Apple?

We had to develop experts on Mac OS X fairly quickly. We do have a number of people in the tools development teams, and in our application performance engineering teams that are focused on Mac OS X and Xcode. They help us ensure we comprehend changes to the environment so that we can plan corresponding changes to our tools. We have established a good working relationship with Apple’s applications and tools teams to ensure there is a good transfer of knowledge of the microprocessor architecture and tuning, and for Mac OS X knowledge back to Intel. Our teams worked well together to teach each other what we needed to know, and answer questions we had either way.

Obviously the compiler group has to work closely with hardware engineers designing the CPU’s. At what stage in the development of a new CPU do the groups begin to interact to lay out a strategy for integrating support for new features into the compiler tools and libraries?

The tools and application performance teams get involved with the processor architects very early – during the conceptual design of the processors and new features, and through simulation/emulation prior to tapeout. We want to ensure that new processors support features that are important to a wide variety of software, and that the features are such that the tools can take advantage of them.

Commercial versions of the Intel C/C++ and Fortran compilers, as well as the Intel Performance Primitives and the Intel Threading Building Blocks, are already available for purchase. Approximately how long did it take to get the product shipping? What were some of the steps that had to be taken to get the project going initially?

It took us about a year to get the tools products ready. We had a small number of people that began investigation and prototyping work in complete secrecy from the rest of Intel beginning a few months before the WWDC 2005 announcement. After the announcement we were able to do full product planning without the veil of secrecy. It took about nine months from July 2005 to April 2006 when the Compilers and Libraries were released as products. We were in great shape in January 2006 and able to get a lot of developers using our preview (beta) once the MacWorld announcements were public.

During the beta period for the Intel compilers, I was extremely impressed with the integration of the C/C++ and Fortran compilers. In fact for a number of applications I was porting at the time, it was often as simple as using the icc/ifort Makefiles for Linux. What has the response been to the compilers from the Mac OS X community?

We have been very pleased with the reaction to our tools. At WWDC 2006, in the Performance Lab, we were able to witness a number of developers trying the tools or showing us the results of using them. Many cited big performance gains from them, and are pleased with the way they are integrated and are compatible with GCC and Xcode.

By almost every performance metric, the new Intel Core 2 microarchitecutre is a success. What are some of the new features in these CPUs that make them so powerful? What type of additional functionality has been added to the compilers to help programmers take advantage of newer features present on these CPUs?

The key features in the Intel® Core™ 2 Duo processors are the dual-core/multi-threading capability, the SIMD execution engine for the Streaming SIMD Extensions instruction set architecture, the very advanced cache design, and the lower power consumption.

The compilers allow users to take advantage of multi-threading through the support of the OpenMP* standard and auto-parallelization. OpenMP (details can be found at www.openmp.org) is a directive-based application programming interface (API) that allows the user to specify which parts of the code to parallelize, such as loop nests, and how to share or protect data. The compiler converts the directives into calls to the underlying OpenMP runtime library for implementation and scheduling of the threads. Auto-parallelization is where the compiler attempts to parallelize loop nests automatically, with little direction from the user.

To take advantage of the SIMD capabilities, the compiler will automatically vectorize code by generating the appropriate SSE/SSE2/SSE3 or SSSE instructions utilizing the SIMD registers for parallel execution. We also pay close attention to how we optimize loop nests for memory and cache utilization.

Scientists tend to have very computationally demanding applications. What has Intel’s approach been in the past toward scientific applications of their compiler technology? What features of the Intel developer tools do you think might be of particular use for scientific code?

Scientific applications are typically very computationally intensive, and thus, performance sensitive applications. Therefore, we pay close attention to their application performance as it showcases the capabilities of our processors.

We have spent many years perfecting the capability of the compiler to vectorize the key loops of many different types of scientific applications to take advantage of the SIMD features of the Intel processors. Many such applications can be very sensitive to floating-point precision. Higher levels of optimization can impact that as we may do some optimizations such as replacing a floating-point divide or square root with a reciprocal approximation, for example. To alleviate this, we have implemented a floating-point precision vs. performance tradeoff model to allow the user to specify how much precision can be traded for additional performance. In addition, we have highly tuned our math library (libm) that implements the common transcendental functions (sin, cos, tan, exp, etc.) and other math primitives to ensure it provides the best possible precision and performance for our processors, and thus, the user’s applications.

The Intel® Math Kernel Library implements the commonly used linear algebra domains (BLAS, LAPACK), sparse solvers, fast-fourier transforms, and random number generators. All of these are commonly used in the scientific community. These libraries are able to dynamically detect the processor type and threading capability (number of cores and processors) of the system on which it is running to invoke best implementation of the function for that processor, and with the right number of threads. This library can save a lot of time in performance tuning and threading.

The new Core 2 CPUs are 64-bit. A lot of scientific applications can benefit from the ability to address more than 4GB of memory (especially image processing applications). Are the Intel compilers currently capable of producing 64-bit binaries on the newer Mac Pro and iMac based systems? If not, when can we expect this functionality to be added?

The current shipping version of the Intel compilers is version 9.1. These compilers will generate code only for 32-bit applications, thus addressable memory is ~2GB. Our next compiler version will be in preview (beta testing) by early 2007 and will support 64-bit addressing. If one wants to join the beta program, please submit your email address to us at www.intel.com/software/products/apple and someone from my team will contact you when the beta program is available.

Developers may want to move to 64-bit binaries even if they are not addressing over 2GB of memory. This is because the number of processor registers available with 64-bit instructions is higher in the Core 2 micro-architecture. More registers will often result in higher performance for applications since the compiler can keep more data in them versus having them in memory.

One aspect of scientific code that many of us deal with is the massive code base that is in Fortran. Intel provides a high performance Fortran compiler. Who are some of the biggest adopters (on all platforms) for the various compiler technologies that Intel provides?

We are pleased to have arguably the best Fortran compiler for Mac OS X. We have worked with many major software vendors and end users in the scientific computing arena. Many of the national laboratories and government agencies use our products, as do many leading research universities. Also, we’ve seen great interest from leading researchers in the bio-sciences.

With the addition of Mac OS X to the Intel repertoire of supported platforms come additional technologies and programming languages that are unique to this particular environment. One of those languages is Objective-C. Does Intel plan to offer support for Objective-C in the future as an add-on to the C/C++ compilers?

We are looking at adding Objective-C support, but do not have plans to support it at this point. The Xcode environment is smart enough to use our compiler for C++ and C code and direct Objective-C code to the Apple compiler. This means our lack of support does not stop developers from getting some benefit for programs using a mixture of code.

Looking ahead, what are some of the new features that we can look forward to being added to the Intel developer tools and how will they be useful for those of us on Mac OS X, and in particular for scientists?

We are focused on adding 64-bit support for Mac OS X this year. Additionally, even though we believe we are the best compiler anywhere for multi-threading, we are really just scratching the surface of multi-threading capabilities. We want to expand the utility of auto-parallelization to make it able to thread more loops. The Intel® Threading Build Blocks is an example of how we want to find new and more efficient ways for developers to express parallelism. It was also the first new product since we started supporting Mac OS X, and so it became the first product to debut on Mac OS X the same day as the debut on Windows and Linux.

We know that abstraction of thread management is important, we know making it easy to debug and tune is important – and eliminating the need to debug or tune is even better. I think we have some great ideas which will lead to more and more support for developers.

We want to continually improve the capability of debugging threaded and optimized code so that developers don’t have to build both debug and optimized versions.

To many people the switch to Intel came as a big surprise, and for the majority of us, we found out during the WWDC 2005 keynote, including many people within Apple. At what level within Intel was the transition known about prior to the announcement? Can you describe some of your initial thoughts when you first found out about the switch?

As I said above, there were just a few people in the company in senior management and key software and hardware technologists that knew about it early on. Personally, I was ecstatic. Apple is such an innovative and creative company; we knew we could learn some interesting things in working with them. It meant that I could lift my self-imposed embargo on buying a Mac for my family because it did not have an Intel processor in it.

Of course, now that Mac’s come with Intel CPUs, do you expect to start seeing more Mac’s around the offices at Intel?

I hope so. There is a lot of interest in that. Right now, our group is developing software for Apple machines so we definitely see a lot more Apple machines around our offices.

The post Interview: Joe Wolf – Intel Security Compiler Group appeared first on MacResearch.org.