Re: multi CPU's
Tom Rothamel wrote:
>
> On Thu, Apr 06, 2000 at 07:28:06AM +0300, Eray Ozkural wrote:
> > Is it totally different? That was my implicit question. Don't you
> > think there should be only a marginal difference between the two
> > images, since saying SMP just switches a few preprocessor symbols
> > here and there. Then, the bulk of the binary code would be same.
> > Though I'm pretty sure those preprocessor symbols are then scattered
> > all over the megs of source code. But that seems to be less than 1000.
> > [I've checked].
>
> Yes, but the generated binary is then gzipped, causing the small
> changes to greatly preturb the output. Also, generally, when program
> source code changes, the diffs between the resultant binaries is
> large. (Ie, ddiff is only useful for minor packaging changes, rather
> than full new releases, although this may vary if a package uses a lot
> of static data files.)
Of course that's because of the kernel. The linux kernel source gzips
its output. bzImage... But how about the modules? I thought they were
not zipped. I'd suppose that ddiff runs over unpacked packages, so that
kind of perturbations don't incur extra penalty. Is that correct? So, what
you say only applies to vmlinuz, which is small compared to modules. Plus,
if there's such an effect of gzipped files, shouldn't ddiff unpack them
on-the-fly, do the diff and mark as a gzip file?
And about that source code changes result in an explosion of binary change,
I think that depends on the code and the prog. lang. If I wrote 100K of
assembly code, and changed a single line, only a few bytes would be affected.
However, if I change some lines in libstdc++, I might really cause the
kind of exponential explosion which you refer to. For plain C code like Linux,
I'd expect that the binary code change is not much longer than slightly
superlinear wrt source code length.
>
> > If I remember correctly from my grad. algorithms course, the diff
> > tools use hyper-cool dynamic prog. stuff... which will just give you
> > the differences :) Anyway, what do you think would be the ddiff
> > output? Or shall we just try and see? My estimate is that it will
> > be less than 512k, and perhaps much smaller. And I guess that the
> > incurred cost will be very small for some other desirable options
> > that can't be built as modules.
>
> Please note that my kernel is only on the order of 600k or so. I'm
> wondering if there's a way to build modules so that they can be used
> with or without SMP support, which is perhaps the biggest change
> between kernels.
>
I'd meant the whole kernel package.
-r--r--r-- 1 root root 4265368 Mar 23 06:23
/home/ftp/debian/dists/potato/main/binary-i386/base/kernel-image-2.2.14_2.2.14-2.deb
that's over 4 megs. A 150k SMP diff wouldn't be bad.
> > Of course, it would be best if ddiff worked transparently from the user's
> > point of view. Then, the user would see different packages which are in fact
> > patched in place with ddiff.
>
> My eventual vision of ddiff would be integration with apt... I'm not
> sure how relavent that is in this case, however.
>
Not very relevant, but I think it ought to work with apt. It would
be then quite convenient.
--
++++-+++-+++-++-++-++--+---+----+----- --- -- - -
+ Eray "eXa" Ozkural . . . . . .
+ CS, Bilkent University, Ankara ^ . o . .
| mail: erayo@cs.bilkent.edu.tr . ^ . .
Reply to: