How to auto-parallelize a binary code?
yunzhi
several years ago but the source code is gone.
Now for other reason, we want to immigrate this application to a
multi-core computer with Core cpu, which has 4 cores. Is there any
chance to improve performncce of this application on new computer
without re-compliation?
I do know the single-thread performance will be improved. But how to
auto-parallelize this binary code? Are there any tools or related
research?
Best wishes,
yunzhi
[Don't hold you breath. -John]
Louis Krupp
Start rewriting the application *now*. Without the source code, all it
takes is one change of computer architecture or one incompatible OS
upgrade, and you won't be able to run your app at all. Don't wait until
this is about to happen; do the rewrite while you still have plenty of
time to compare results with the old version and make sure you've got it
right.
(Decompilers have been discussed in this group. I don't recall what the
consensus was.)
Louis
[Except in rare occasions with highly stylized code, I've never seen a
decompiler that was much more than a disassembler with a little syntactic
sugar. I agree that in the long run there's no substitute for rewriting
the program to do what you want it to do. -John]
j...@cix.compulink.co.uk
> I do know the single-thread performance will be improved. But how to
> auto-parallelize this binary code? Are there any tools or related
> research?
None that will do you any good with just a binary. Even with source, it's
often a lot harder than vendors of multi-core processors, and of
parallel programming tools, like to imply. You need source code, and for
this app, you're going to have to get that by writing it.
On the bright side, you will at least be familiar with the source code
when it comes to adding parallelism. Indeed, this is often most
effectively done by a re-write. You want to look hard at what the app
does and pick some parallelism techniques before you finish the
reconstruction of the source.
One exception to decompilers: they can do you some good with Java or
..NET code, but it doesn't sound as if that's what you have.
--
John Dallman, j...@cix.co.uk, HTML mail is treated as probable spam.
Jeremy Wright
worked on this application (I assume you have already tried all the
current employees). They may have an old backup tape they kept at
home in case the office building burned down. They may know of backups
on decomissioned servers that are probably sitting quietly in a corner
of your office somewhere.
Even an out of date copy will give you a huge head start.
Jeremy Wright
George Neuner
wrote:
>We have an important single-threaded application. It was developed
>I do know the single-thread performance will be improved. But how to
>auto-parallelize this binary code? Are there any tools or related
>research?
As others have said, rewriting the application is your best bet.
As far as I know there is no current research on auto-parallelizing
native binaries. Back in the 1980's some groups were looking into it,
but rapid advances in single core performance killed interest in the
idea. Virtually all of the tools available now work either at the
source level or at the AST level in the compiler.
If you are desperate for better performance, one thing you might look
into is disassembling the program and re-assembling it to target the
new processor architecture. Modern processors can do a certain amount
of hardware instruction reordering to accommodate older code, but if
you're leaping one or more processor generations, a peephole optimizer
(sometimes called a "window" optimizer) specifically targeted to the
new processor can make a big difference for single core performance.
George
cr88192
Though unlikely to help much in this case, a while ago I remember
running across a paper which was describing auto-parallelizing native
code.
Their idea was basically to disassemble the code and rework it into
SSA form, then do some "funky magic" on it to split it up into
parallel operations (fine-grained AFAIK), and then recompile the code
for the new target (in this case, specialized processor hardware, I
think the task was to get generic x86 code running on a multi-core
risk processor. the paper also compared their approach with that taken
by Transmeta, ...).
I don't remember that much more than this...
I guess the great difficulty would be to pull this off tolerably efficiently
on a conventional OS and HW (without overhead by far exceeding any possible
gain...).
agreed, the OP should do whatever possible to get a source-code version of
the app before it is too late, even rewriting the app if necessary.
however, I will not rule out "decompilers", as even if the output generally
sucks, it may be possible to work it into something that can at least be
recompiled (and serve as a starting point for a complete rewrite, said
rewrite being done "one function at a time"...). I guess whether or not this
would help depends on how fammiliar the available staff/... are fammiliar
with whatever task the compiler performs (if none know what exactly the app
does or how it works, there may be a problem... but if the task is familiar,
a clean rewrite may be in line...).