CASTalk.com

And you guys said it was hard..... :-)
Anyway it might be of some interest. See I don't only post IBM stuff

http://www.reed-electronics.com/electro ... =CA6292650

NEC Develops Multicore Processor Technology with Automatic Parallelization
Online staff -- 12/19/2005
Electronic News


NEC Corp. today announced that it has succeeded in the development of
multicore processor technology capable of performing automatic
parallelization of application programs, without modifying them.

Advertisement

As described by the company, key features of the multicore processor
technology include an automatic parallelizing compiler, capable of
effective extraction of parallelism from an application program using
its profile information; an additional instruction-set, designed to
minimize parallelization overheads; processor architecture, which
handles speculative execution; and implementation realized by a simple
extension to conventional processors.

The distinctive feature of this new technology is the ability of the
automatic parallelizing compiler that utilizes profile information to
exploit parallelization patterns, which are effective for accelerating
the speed of application programs. In addition, although the
parallelization is speculative, the speculation is almost always
completely accurate, according to NEC.

The speculation hardware works as a safety net by handling any rare
misses, guaranteeing the correctness of the execution and ensuring that
the compiler is not conservative in decisions concerned with these
cases, resulting in an increase in the amount of parallelism exploited,
the company explained. The parallelism exploitation is supported by the
speculative execution hardware that realizes efficient handling of
detection of incorrect execution orders caused by the parallel execution
of the program parts, cancellation of the incorrectly executed part, and
re-execution of it. Moreover, the parallelization process can be
performed in a practical period of time, NEC said.

Parallelization with conventional multiprocessor technology requires the
manual modification of application source programs, which increases the
development and verification cost for software development, which is in
turn made more complex by the growing size and complexity of the
software itself. Multiprocessor technology that can automatically
parallelize application programs without manual modification, NEC said,
has been long sought after in this field.

The newly developed technology realizes automatic parallelization of
application programs and a dramatic reduction in time and cost of
parallelization. NEC noted one test that showed manual parallelization
of an application program took four months of time with one person
carrying out the task, however, automatic parallelization cut this time
to just three minutes with no manual labor involved at all. In addition,
the application program that has been parallelized manually runs 1.95
times faster with four processors than the original application program
running with one processor, the company said.



--
Del Cecchi
"This post is my own and doesn’t necessarily represent IBM’s positions,
strategies or opinions.”

David Kanter <dkanter@gmail.com> wrote:

I wonder if they can compile SPEC with this...

DK

Sun already posts SPECfp2k numbers with and without autoparallelization,
so I won't be surprised at all if NEC can improve SPECfp2k numbers.
SPECint2k is a totally different ballgame and I'd be surprised
if they can get more than 10-20% on most SPECint2k.
--
#pragma ident "Seongbae Park, compiler, http://blogs.sun.com/seongbae/"

In article <40oia4F1aflgeU1@individual.net>,
Del Cecchi <cecchinospam@us.ibm.com> wrote:

Anyway it might be of some interest. See I don't only post IBM stuff

Yes, but you posted something which looks like the usual
auto-parallelization which is available in many compilers, such as the
ones from Intel, IBM, Sun, PathScale, etc etc. Did you not realize
this? This kind of technology has been around since, oh, 1990.

-- greg

I wonder how they reorganize FP computations
and end up with IEEE 754 accurate results!

This problem isn't related especially to parallelization.

I wonder how they reorganize FP computations and end up with IEEE 754
accurate results!

I wonder if they can compile SPEC with this...

DK

"Greg Lindahl" <lindahl@pbm.com> wrote in message
news:43a7328c$1@news.meer.net...

In article <40oia4F1aflgeU1@individual.net>,
Del Cecchi <cecchinospam@us.ibm.com> wrote:

Anyway it might be of some interest. See I don't only post IBM stuff

Yes, but you posted something which looks like the usual
auto-parallelization which is available in many compilers, such as the
ones from Intel, IBM, Sun, PathScale, etc etc. Did you not realize
this? This kind of technology has been around since, oh, 1990.

-- greg

They also mentioned something about hardware. "The speculation hardware
works as a safety net by handling any rare
misses, guaranteeing the correctness of the execution and ensuring that
the compiler is not conservative in decisions concerned with these
cases, resulting in an increase in the amount of parallelism exploited,
the company explained. The parallelism exploitation is supported by the
speculative execution hardware that realizes efficient handling of
detection of incorrect execution orders caused by the parallel execution
of the program parts, cancellation of the incorrectly executed part, and
re-execution of it"

But, hey, I'm a circuit designer. What do you expect. This made
Electronic News. I figured it must be news.

del

Yes, but you posted something which looks like the usual
auto-parallelization which is available in many compilers, such as the
ones from Intel, IBM, Sun, PathScale, etc etc. Did you not realize
this? This kind of technology has been around since, oh, 1990.

No, it doesn't sound like that at all - it's just in the same general
direction. As Del points out, the compiler gets more latitude because
of the speculative execution features, and I haven't heard yet that
profile-based feedback is used to drive parallelization, although that
might have happened before to some degree.

Jan

Sun already posts SPECfp2k numbers with and without autoparallelization,

Would have a pointer to those? Navigating the mass of SPEC results is
quite difficult, so any help would be appreciated.

Jan

PS: Purely selfish interest, of course...see 187.facerec.

Greg Lindahl <lindahl@pbm.com> wrote:

Yes, but you posted something which looks like the usual
auto-parallelization which is available in many compilers, such as the
ones from Intel, IBM, Sun, PathScale, etc etc. Did you not realize
this? This kind of technology has been around since, oh, 1990.

I suspect it's not quite that. NEC have been researching coarse grain
speculative threading for years. The idea being that you speculatively
execute ahead of branches on both execution paths then cancel the incorrect
thread as soon as you know if the branch was actually taken or not.

NEC were looking at implementing an existing architecture using this
technique but they obviously came to the conclusion that they could get
better performance with some compiler support probably to add hinting
instructions. The same way as you can get better usage of caches with
carefully used prefetch instructions, which architecturally are just NOPs.

I suspect NEC have combined this with conventional feedback directed
optimisation such that you don't execute down both paths of all branches,
only ones you can't predict with high certainty, and also doing conventional
autovectorisation of some loops to vector units.

-p
--
"What goes up must come down, ask any system administrator"
--------------------------------------------------------------------

Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> wrote:

Sun already posts SPECfp2k numbers with and without autoparallelization,

Would have a pointer to those?

Without autopar:
http://www.spec.org/osg/cpu2000/results ... 02000.html

With autopar:
http://www.spec.org/osg/cpu2000/results ... 02001.html

As you can see, only a few benchmarks benefit
(in particular, swim, mgrid, applu, galgel
all of which show up in SPEC OMPM2001 benchmark as well).

Navigating the mass of SPEC results is
quite difficult, so any help would be appreciated.

Well, I use SPEC search:

http://www.spec.org/cgi-bin/osgresults?conf=cpu2000

Jan

PS: Purely selfish interest, of course...see 187.facerec.

I'm afraid facerec doesn't see any gain with autopar.
--
#pragma ident "Seongbae Park, compiler, http://blogs.sun.com/seongbae/"

In article <40psofF1bnqiqU2@individual.net>,
Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> wrote:

and I haven't heard yet that
profile-based feedback is used to drive parallelization, although that
might have happened before to some degree.

It's a standard feature -- the main feedback is whether or not a loop
has enough work to make parallelization worthwhile.

-- greg

I'm afraid facerec doesn't see any gain with autopar.

That _is_ surprising, because it is trivial to parallelize. In fact, using
OMP John Henning took only a short time to get a first reasonable version.
Perhaps because the parallelism, while being loop-level, is hidden in a
subroutine and the inter-procedural analysis isn't good enough to notice
that it can be safely parallelized?

Jan

It's a standard feature -- the main feedback is whether or not a loop
has enough work to make parallelization worthwhile.

OK, that I can easily see. I did get the impression from the article,
though, that feedback was also driving the decision on whether to speculate
or not. But that's perhaps pure speculation...

Jan

Well, I guess I'll ask John if he saw anything obvious.
Most likely it is due to bad heuristic or as you said, shortcomings of
IPA.
Usually the hardest part of autopar is to pick up the right level to
parallelize
and if the autopar picked the wrong level, then you don't see much
gain.

Seongbae - usually as seongbae.park@sun.com,
http://blogs.sun.com/seongbae/