Intel acquiring Pallas

Vann H. Walke walkev at
Thu Aug 28 12:49:25 EDT 2003


Not to throw water on hopes for parallelizing compilers and Intel
supported parallel debuggers, but my guess is that Intel's move is much
less revolutionary (but perhaps still important).  

Pallas's main HPC product is Vampir/Vampirtrace.  These are performance
analysis tools.  As such they would only be peripherally useful for
compiler design (perhaps to measure the effects of certain changes). 
Even for this purpose, Vampir/Vampirtrace doesn't provide the amount of
detail that Intel's own V-Tune product does.  

For debugging, Pallas resells Etnus Totalview.  For compiler options
Pallas has the Intel compilers as well as PGI.  As far as I can tell,
Pallas doesn't do any significant independent development for these

So, what does the Pallas performance analysis product do that is
important?  Vampir/Vampirtrace allows the collection and display of data
from a large number of programs running in parallel.  Doing this well is
not trivial.  Time differences between machines must be taken into
account.  The tools  must be able to handle a potentially huge amount of
trace data (running a profiler on a 1000 process system is a much
different animal from instrumenting a single process job).  And, finally
once all this data is collected it has to be presented in some way which
can actually be of use.  VA/VT is among the best available tools for
this purpose.

So, why would Intel want to acquire Pallas?  First, they have a good
product which can be sold at a high price.  Combined with some Intel
marketing they "should" be able to make money on the product.  Second,
Vampirtrace has the capability of using processor performance counters. 
By pushing the capabilities of VA/VT to work on Intel processors it
promotes "lock-in" to Intel processors.  In this way a developer using
the Intel compilers, V-Tune for single process analysis, and Vampir for
parallel profiling, wouldn't be likely to move to an AMD or Power

Is this a good thing?  For the most part probably so.  Intel should be
able to help improve the Vampir software.  Making it work even better on
Intel processors doesn't really hurt things if you're using another
system and might make things really nice for those of us on Intel
hardware.  Hopefully it's development on other systems won't languish.  

But, on the basis of this acquisition, I wouldn't hold my breath for
parallel compilers or a full fledged Intel return to the HPC market.

Presearch, Inc.

On Thu, 2003-08-28 at 12:05, Robert G. Brown wrote:
> On Thu, 28 Aug 2003, Jeffrey B. Layton wrote:
> > to bypass the PCI bottleneck. Of course they could also be after the Pallas
> > parallel debuggers to integrate into their compilers (like you mentioned)
> > or perhaps to help with debugging threaded code in the hyperthreaded chips.
> >    Not that you mention it, this is a somewhat interesting development.
> > I wonder what they're up to?
> My guess is something like this, given what pallas does, but if this is
> the case, they may be preparing to attempt a task that has brought
> strong programmers to their knees repeatedly in the past -- create a
> true parallel compiler.  A compiler where the thread library
> transparently hides a network-based cluster, complete with migration and
> load balancing.  So the same code, written on top of a threading
> library, could compile and run transparently on a single processor or a
> multiprocessor or a distributed cluster.  Or something.
> Hell, they're one of the few entities that can afford to tackle such a
> blue-sky project, and just perhaps it is time for the project to be
> tackled.  At least they can attack it from both ends at once -- writing
> the compiler at the same time they hack the hardware around.  But
> they're going to have create a hardware-level virtual interface for a
> variety of IPC mechanism's for this to work, I think, in order to
> instrument it locally and globally with no particular penalty either
> way.  Or, of course, buy SCI and start putting the chipset on their
> motherboards as a standard feature on a custom bus.  Myricom wouldn't
> like that (or Dolphin if they went the other way), but it would make a
> hell of a clustering motherboard.
>    rgb
> Robert G. Brown	             
> Duke University Dept. of Physics, Box 90305
> Durham, N.C. 27708-0305
> Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at
> _______________________________________________
> Beowulf mailing list, Beowulf at
> To change your subscription (digest mode or unsubscribe) visit

Beowulf mailing list, Beowulf at
To change your subscription (digest mode or unsubscribe) visit

More information about the Beowulf mailing list