5:23 a.m.
The current discussion about breaking up XEmacs in modules is
interesting, but imhnso loses a bit when confronted to reality. Lemme
remind you some basic facts of life:
1- Modules are slow.
Modules must be compiled as a position independant code in order to be
loadable dynamically. This is particularily bad on x86 where it hogs
one register for that and hence forces the compiler to generate much
less efficient code. I plan to fix that for linux in the future, but
it will be a 2.3 project, and linux isn't the only OS out there.
Calls to module functions can't be inlined. This, in particular,
concerns Mule. Don't even _think_ about changing the current Mule
macros to function calls. Or be ready to crawl.
2- Module versioning is a pain
Given the current state of the code we can't expect a module to work
with anything else than the executable it was compiled with (count the
#ifdefs in the source). This is btw more or less the same situation
than with the linux kernel.
Because of that, the first problem is going to be "I downloaded XEmacs
21.6.66 and it crashes at startup - Did you check the module versions
? - Ooops sorry, there was an old condom.so there from XEmacs 21.4.2".
The other problem is how to install two different versions of XEmacs
simultaneously. And no, I do not mean to different version numbers.
I usually have on irix 4 or 5 differently compiled XEmacs executables
(with/without debugging, with/without mule, with/without gung-ho, and
my personally hacked versions). All the lisp and lib-src files are
shared between all of them.
3- Modules and undumping aren't really compatible
Undumping requires loading a lot of lisp. Said lisp uses most of the
functions that would end up in modules, hence all the modules will
have to be loaded. Worse, the data and bss sections of these modules
will have references to the lisp code. Do we want to write a module
undumper?
4- Bloat is in the eye of the beholder
Sorry to say that, but "I dont buy the argument that everything that
is unused is swapped either" shows a lack of understanding of modern
VMs. Unused code or data isn't swapped, it isn't loaded at all. And
code pages or unmodified data pages aren't swapped but discarded.
I also fail to see in which way having a 3.1Mb executable and a 1.1Mb
module is any better than having a 4Mb executable including both
(indirect calls to functions, lack of inlining and alignment
constraints in .so have both a speed and a size cost).
OG.
10:03 p.m.
On Thu, Jan 14, 1999 at 06:23:06AM +0100, Olivier Galibert wrote:
1- Modules are slow.
Modules must be compiled as a position independant code in order to be
loadable dynamically. This is particularily bad on x86 where it hogs
one register for that and hence forces the compiler to generate much
less efficient code. I plan to fix that for linux in the future, but
it will be a 2.3 project, and linux isn't the only OS out there.
With respect, I suggest that you re-examine the ABI, and especially
how trampolines and shared loading works. Linux isnt a reference
platform for PIC code, SVR4 is. If Linux handles trampolines incorrectly,
thats Linux's problem. There is NO reason that it should be slower than
other code. If this was true, hello.c would be slow, every single X
application (not to mention the X server) would be slow etc, as they
all used shared libraries (libc.so, libX11.so etc). All of those shared
libraries are compiled in PIC code. Do you REALLY think that PIC is that
bad? Register spilling in a compiler, and the misuse of registers, is
not an "order of magnitude" difference. Quite often you have to examine
individual instruction cycles to get down to microsecond timing
differences. Its not that big of a deal, and if trampolines are done
properly, there is a one-time overhead on load. Thereafter, the addresses
are bound. Problem solved.
2- Module versioning is a pain
Given the current state of the code we can't expect a module to work
with anything else than the executable it was compiled with (count the
#ifdefs in the source). This is btw more or less the same situation
than with the linux kernel.
Because of that, the first problem is going to be "I downloaded XEmacs
21.6.66 and it crashes at startup - Did you check the module versions
? - Ooops sorry, there was an old condom.so there from XEmacs 21.4.2".
Considering how I envisage them being built, this wont be a problem.
The modules live in the architecture dependant directory, which has
the XEmacs version number in it. For user-installed modules in the
site-modules directory, there is an explicit check for the version, and
the module wont load if the versions mis-match. Please, dont assume that
a new feature requires NO work and discipline on behalf of the people
who use it. And I already anticipated this problem, which is why each
module is stamped with the module loading version (i.e. the version of
the module loading technology itself, not the XEmacs version). At any
time that incompatible changes are introduced into XEmacs, all that is
required to bump that version, and everything that came before it won't
load. Simple, but very effective.
The other problem is how to install two different versions of
XEmacs
simultaneously. And no, I do not mean to different version numbers.
I usually have on irix 4 or 5 differently compiled XEmacs executables
(with/without debugging, with/without mule, with/without gung-ho, and
my personally hacked versions). All the lisp and lib-src files are
shared between all of them.
Modules are by their very definition architecture
dependant, and as
I said above, the architecture has the XEMcs version as a function of
it. Aside from that, there is still a good chance that modules will load
from version to version, and this will remain true unless there are very
fundamnetal changes within XEmacs, which is what the internal module
version number is for. There is NO argument that modules will tkae a little
bit of extra care if you really want to share multiple versions of XEMacs,
but lets face it, the only people that do that in the REAL world are XEmacs
developers, and they can cope with the small overhead easily.
3- Modules and undumping aren't really compatible
Undumping requires loading a lot of lisp. Said lisp uses most of the
functions that would end up in modules, hence all the modules will
have to be loaded. Worse, the data and bss sections of these modules
will have references to the lisp code. Do we want to write a module
undumper?
Eh? I dont understand this objection at all. Why do you want to undump
something that is dynamic? Please expand on this more so that I can
understand the objection / limitation.
4- Bloat is in the eye of the beholder
Sorry to say that, but "I dont buy the argument that everything that
is unused is swapped either" shows a lack of understanding of modern
VMs. Unused code or data isn't swapped, it isn't loaded at all. And
code pages or unmodified data pages aren't swapped but discarded.
Sir, I
understand modern VM's very well. I have helped write one of the
most sophisticated and modern ones around (except for MPE - thats still
the most kick-ass OS I have ever seen). Yes, the VM will swap out pages
when it needs to, but there's the rub, do we REALLY want to force the VM
into that state if we dont need to? Netscape does the Wrong Thing by
having such a monolithic binary, and XEmacs is headed the same way. The
entire UNIX philosophy is to keep things small, and grow on demand, not
start huge and discard on demand.
--
J. Kean Johnston | "If equal affection cannot be,
Engineer, SPG | let the more loving one be me" - W.H. Auden
Santa Cruz, CA +----------------------------------------------------------
Tel: 831-427-7569 Fax: 831-429-1887 E-mail: jkj(a)sco.com
12:18 a.m.
On Thu, Jan 14, 1999 at 02:03:31PM -0800, J. Kean Johnston wrote:
On Thu, Jan 14, 1999 at 06:23:06AM +0100, Olivier Galibert wrote:
> 1- Modules are slow.
>
> Modules must be compiled as a position independant code in order to be
> loadable dynamically. This is particularily bad on x86 where it hogs
> one register for that and hence forces the compiler to generate much
> less efficient code. I plan to fix that for linux in the future, but
> it will be a 2.3 project, and linux isn't the only OS out there.
With respect, I suggest that you re-examine the ABI, and especially
how trampolines and shared loading works. Linux isnt a reference
platform for PIC code, SVR4 is. If Linux handles trampolines incorrectly,
thats Linux's problem. There is NO reason that it should be slower than
other code.
With respect, it is well known that PIC code is slower than non-PIC
code in most architectures. I think the only exception may be mips,
mostly because SGI for irix decided ages ago that "all code must be
pic". Ask your compiler-writer friends.
If this was true, hello.c would be slow, every single X
application (not to mention the X server) would be slow etc, as they
all used shared libraries (libc.so, libX11.so etc).
So ? LibX11 _is_ slow, Motif crawls, and gtk+ isn't much better. The
slowdown due to the PIC code is hidden by the bigger slowdown caused
by the X protocol. Sirius company maybe ?
Did you know that the INN 2.1 (or maybe 2.0, I don't remember exactly)
huge slowdown on linux was due to changing the compilation mode to a
shared library by default?
All of those shared
libraries are compiled in PIC code. Do you REALLY think that PIC is that
bad? Register spilling in a compiler, and the misuse of registers, is
not an "order of magnitude" difference.
On the register-starved architecture that is the x86 and at least with
gcc, it is. Most interesting adressing modes aren't PC-relative too.
Quite often you have to examine
individual instruction cycles to get down to microsecond timing
differences. Its not that big of a deal, and if trampolines are done
properly, there is a one-time overhead on load. Thereafter, the addresses
are bound. Problem solved.
1- You won't be using trampolines but function pointers because it is
dynamically loaded modules we're talking about, and not shared
libraries. OTOH, direct function pointer callings are faster.
2- What we're talking about is function call (trampoline or indirect)
vs. _inline_. The 30% slowdown of mule is mostly due to the fact that
moving to the surrouding characters is more complex than p++ and p--,
and you would want to change that to a _function_call_ ?
> The other problem is how to install two different versions of
XEmacs
> simultaneously. And no, I do not mean to different version numbers.
> I usually have on irix 4 or 5 differently compiled XEmacs executables
> (with/without debugging, with/without mule, with/without gung-ho, and
> my personally hacked versions). All the lisp and lib-src files are
> shared between all of them.
Modules are by their very definition architecture dependant, and as
I said above, the architecture has the XEMcs version as a function of
it. Aside from that, there is still a good chance that modules will load
from version to version, and this will remain true unless there are very
fundamnetal changes within XEmacs, which is what the internal module
version number is for. There is NO argument that modules will tkae a little
bit of extra care if you really want to share multiple versions of XEMacs,
but lets face it, the only people that do that in the REAL world are XEmacs
developers, and they can cope with the small overhead easily.
A lot of people are installing both the MULE and non-MULE version of
xemacs on the same system. MULE and non-MULE modules won't be
compatible at all.
> 3- Modules and undumping aren't really compatible
>
> Undumping requires loading a lot of lisp. Said lisp uses most of the
> functions that would end up in modules, hence all the modules will
> have to be loaded. Worse, the data and bss sections of these modules
> will have references to the lisp code. Do we want to write a module
> undumper?
Eh? I dont understand this objection at all. Why do you want to undump
something that is dynamic? Please expand on this more so that I can
understand the objection / limitation.
XEmacs isn't an editor written in C. XEmacs is written in emacs lisp.
The C part is constituted of:
- the core lisp engine
- all the basic tasks involving the environment (accessing files,
drawing to screen...)
- some functions that could have been written in lisp, but would have
been too slow as a result
Part of the building process of XEmacs is called the undumping. A
bunch of lisp is loaded which "plugs" into the C level through static
variables (the staticpro'ed ones) and then a new executable is created
which includes said lisp.
If you use modules for parts of the engine, you will need to find some
way to link back said static variables to the lisp code. I wouldn't
even know where to start.
> 4- Bloat is in the eye of the beholder
>
> Sorry to say that, but "I dont buy the argument that everything that
> is unused is swapped either" shows a lack of understanding of modern
> VMs. Unused code or data isn't swapped, it isn't loaded at all. And
> code pages or unmodified data pages aren't swapped but discarded.
Sir, I understand modern VM's very well. I have helped write one
of the
most sophisticated and modern ones around (except for MPE - thats still
the most kick-ass OS I have ever seen). Yes, the VM will swap out pages
when it needs to, but there's the rub, do we REALLY want to force the VM
into that state if we dont need to? Netscape does the Wrong Thing by
having such a monolithic binary, and XEmacs is headed the same way. The
entire UNIX philosophy is to keep things small, and grow on demand, not
start huge and discard on demand.
Sir, if your VM is loading the full executable in memory at the start
and then discard what is unused, you have a problem there. Also, I am
sure that you know the not so subtle difference between "swapping out"
and "discarding", so it would be nicer that you stop using them
interchangibly. Stop writing as if you don't know what you're talking
about, and I won't consider that it is the case anymore.
For the people out there who don't understand modern VMs very well,
let me outline two scenarios where a user wants to use for the first
time a DB function:
a- monolithic executable:
- the function is called
- page fault, the code is loaded in memory. A bit of read-ahead of
the code is done before and after the function
- the function runs
b- module
- the program sees that the function is not in memory
- the module is found and the function table is loaded (but not the
function code itself, usually)
- the function pointers are updated
- the function is eventually called. Go to a.
Guess who's fastest ?
OG.
2:17 a.m.
On Fri, Jan 15, 1999 at 01:18:37AM +0100, Olivier Galibert wrote:
2- What we're talking about is function call (trampoline or
indirect)
vs. _inline_. The 30% slowdown of mule is mostly due to the fact that
moving to the surrouding characters is more complex than p++ and p--,
and you would want to change that to a _function_call_ ?
Not at all ... MULE was
stated as a POSSIBILITY, and there are obvious
reasons why that should be discounted. Something as fundamental as
MULE or MINIMAL_TAGBITS can not, of course, be modulized.
A lot of people are installing both the MULE and non-MULE version
of
xemacs on the same system. MULE and non-MULE modules won't be
compatible at all.
The obious solution is to have two architecture directories, one
for
MULE and one without. They will have to keep two versions of ellcc around
for the module compiler too, since it is installed in $(bindir) not into
$(archlibdir).
XEmacs isn't an editor written in C. XEmacs is written in emacs
lisp.
The C part is constituted of:
- the core lisp engine
- all the basic tasks involving the environment (accessing files,
drawing to screen...)
- some functions that could have been written in lisp, but would have
been too slow as a result
Part of the building process of XEmacs is called the undumping. A
bunch of lisp is loaded which "plugs" into the C level through static
oh
you meant unEXECing. The terminolgy you used confused me. What you
really mean is dumping, or unexecing. undumping is a double-take :-)
If you use modules for parts of the engine, you will need to find
some
way to link back said static variables to the lisp code. I wouldn't
even know where to start.
Depends. Dont forget that modules add in variables and
functions in the exact
same way they would if you had used (defun ()). If its not a problem for
Lisp functions its not a problem for subr's. I agree that loading modules
into the pure emacs is a bad idea, as they way in which the subrs and
variables are added will lead XEmacs to put them in the dumped version.
However, most of the pre-loaded stuff is supposed to be RELATIVELY autonomous
isn't it?
a- monolithic executable:
- the function is called
- page fault, the code is loaded in memory. A bit of read-ahead of
the code is done before and after the function
- the function runs
b- module
- the program sees that the function is not in memory
- the module is found and the function table is loaded (but not the
function code itself, usually)
- the function pointers are updated
- the function is eventually called. Go to a.
Perhaps you should have a look at
SVR4.2 or SVR5's dlopen() code. I will
check it again (and talk to the God who invented ELF and dlopen() in the
first place to make sure), but the last time I checked, things looked more
like:
b- module
- dlopen() is called on the module. Dynamic loader loads in module and
executed code in the .init section (static constructors, and other
user code if you know what you are doing).
- rtld binds addresses in the offset table to real addresses (code is
no longer position independant, it now has a bound address in a valid
text segment).
- text segment is a candidate for retirement like any other, although it
has a higher bias against discarding.
- function is called, accesses code in text segment and run it, or reloads
if the page was dropped.
This is the conceptual procedure, not an exact description. This is the case
on SVR3.2 and later. Is it THAT much less efficient in other environments?
--
J. Kean Johnston | "If equal affection cannot be,
Engineer, SPG | let the more loving one be me" - W.H. Auden
Santa Cruz, CA +----------------------------------------------------------
Tel: 831-427-7569 Fax: 831-429-1887 E-mail: jkj(a)sco.com
4:55 a.m.
On Thu, Jan 14, 1999 at 06:17:47PM -0800, J. Kean Johnston wrote:
On Fri, Jan 15, 1999 at 01:18:37AM +0100, Olivier Galibert wrote:
> 2- What we're talking about is function call (trampoline or indirect)
> vs. _inline_. The 30% slowdown of mule is mostly due to the fact that
> moving to the surrouding characters is more complex than p++ and p--,
> and you would want to change that to a _function_call_ ?
Not at all ... MULE was stated as a POSSIBILITY, and there are obvious
reasons why that should be discounted. Something as fundamental as
MULE or MINIMAL_TAGBITS can not, of course, be modulized.
Ok. Now it starts to be more reasonable. Things that are already
indirect function calls wouldn't suffer. The objection against PIC
code speed still holds, though.
> A lot of people are installing both the MULE and non-MULE
version of
> xemacs on the same system. MULE and non-MULE modules won't be
> compatible at all.
The obious solution is to have two architecture directories, one for
MULE and one without. They will have to keep two versions of ellcc around
for the module compiler too, since it is installed in $(bindir) not into
$(archlibdir).
Mule isn't the only distinction, it's only one of the worst. For a
long time to come you will have a huge dependency for a module to the
executable it was compiled with.
oh you meant unEXECing. The terminolgy you used confused me. What
you
really mean is dumping, or unexecing. undumping is a double-take :-)
Sorry :-) English isn't my native language.
However, most of the pre-loaded stuff is supposed to be RELATIVELY
autonomous
isn't it?
I'm afraid not. Look at lisp/dumped-lisp.el.
This is the conceptual procedure, not an exact description. This is
the case
on SVR3.2 and later. Is it THAT much less efficient in other environments?
I think it is quite exact, and similar than in other environments.
It's at best not much slower than the monolithic version.
My gripe against your idea of breaking in modules is that for now most
of your arguments are technically wrong. For instance:
This gives users choices they didnt have before (eg, I think I'll
try
loading the Lucid widgets instead of the mOtif ones) and it reduces the
size of the in-memory footprint of Emacs considerably.
The part about flexibility may be true, although I wonder about the
cost. The part about the in-memory footprint is simply wrong. I can
only hope that you're not one of those that can't understand the
difference about real and virtual memory usage. We're talking about
real oses here.
I dont buy the argument that everything that is unused is swapped
either.
Most systems have limited swap space, and why waste 20MB in swap if we
only need to waste 5? Why have hundreds of extra shared pages when we really
only need a few?
Like I said, everything unused is not loaded at all with all decent
VMs.
Emacs used to be a 700K binary. Now its a 2.6MB image and thats
excluding
all of the shared libraries that it loads. We CAN stop this excess.
Maybe, but not by making a bunch of modules which are going to add to
the size of the executable itself.
Actually, I'm not necessarily againt this module thingy. I just don't
see, for now, what we would gain, except from a _lot_ of bugs to cope
with and the freezing of internal interfaces we'd rather want to keep
changeable at will for now.
OG.
9589
days inactive
9590
days old
4 comments
2 participants
participants (2)
-
Kean Johnston -
Olivier Galibert