Stuff Michael Meeks is doing |
Older items: 2008: ( J F M A M J J A ), 2007: ( J F M A M J J A S O N D ), 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, legacy html
One evening during our prayer and Bible study, Mrs Weidema came running from the hospital. "Njonja, please come and pray for my baby," she pleaded. She had been going regularly to nurse the baby, but her milk had dried up and the baby was not responding to the rice water they were using as a substitute. I went back with her my heart torn by that limp and lifeless bit of humanity. We bowed our heads together, and I prayed that the Lord would spare her baby.
Returning to the barracks I was met by another young mother from our barracks, Lennie Ripassa. She had an infant and was nursing. "Meurouw Deibler, I have more milk than I need," she volenteered. "I would be willing to breast-feed the other baby too." Which is exactly what she did, feeding the sick starving baby until he regained strength and both babies were weaned. This was God's answer to prayer. Both of the newborns from our barracks survived.
readelf -s -W -D -I foo.so
output.
Never mind that any half-breed monkey with the brain of a flea that has ever programmed an office suite since Microsoft captured the marketplace has bent over backwards to ensure the highest level of compatibility with MS Office they could offer.He should clearly be more careful whom he offends.
Before: ==27907== D refs: 98,069,403 (73,455,788 rd + 24,613,615 wr) ==27907== D1 misses: 3,963,722 ( 3,943,112 rd + 20,610 wr) ==27907== L2d misses: 179,710 ( 178,441 rd + 1,269 wr) ==27907== D1 miss rate: 4.0% ( 5.3% + 0.0% ) ==27907== L2d miss rate: 0.1% ( 0.2% + 0.0% ) After: ==27871== D refs: 98,067,932 (73,454,588 rd + 24,613,344 wr) ==27871== D1 misses: 1,916,141 ( 1,911,775 rd + 4,366 wr) ==27871== L2d misses: 175,893 ( 174,620 rd + 1,273 wr) ==27871== D1 miss rate: 1.9% ( 2.6% + 0.0% ) ==27871== L2d miss rate: 0.1% ( 0.2% + 0.0% )And of course - that doesn't require any glibc changes, which is nice. Some patch cleanup needed. Conf call with the Intel lads.
elf_hash % bucketcount
- [within the
global/local distinction] ensuring that collisions are as adjacent
in memory for conflicts as possible.
http://red-carpet.go-oo.org/
,
and grab
hypocycloid-demo.xls. In fact, although this is quite a simple, but good
looking macro, we can do way more useful things too, development help appreciated
though.
-z interpose
linker
feature a "ld-preload this library" type flag; might be useful for
the glibc pthreads bits. Installed some development stuff on the slow
laptop with yast2 - there's another app that needs some profiling love -
to speedprof to be compiled. Upgraded to the latest evo. snapshot to get
a different set of bugs: a change is as good as a rest.
get_string, slen, free_list,
list_size, reference
even better than that - in case of a single
instance failing - they're defined by multiple libraries. Mailed Glynn a
list of obvious problems - when you look closer it just gets worse.
Mailed the CDDB author too, and the cdparanoia chap, mailed Dick Porter
about Mono too; gave up - too tiresome; all bugs.
/usr/lib/browser-plugins/libflashplayer.so
export
'strchr', 'strrchr' and 'strlen' symbols ? hopefully Macromedia
know.
/opt/gnome/lib/gaim/docklet.so /opt/gnome/lib/tomboy/libtomboy.so /opt/gnome/lib/evolution/2.4/libeutil.so.0.0.0 implement: egg_tray_icon_new_for_screen egg_tray_icon_cancel_message egg_tray_icon_send_message egg_tray_icon_get_orientation egg_tray_icon_get_type egg_tray_icon_new. Mailed the gstreamer guys too. So far not found a single genuine/deliberate use of interposing in the whole of Gnome / OO.o: clearly not that critical a linker feature.
echo "foo" >> /share/NLD-10-DVD-i386-Alpha2a.iso File size limit exceededAfter some more poking turns out the user-space NFS thing was installed, got the
nfs-utils
package instead of
nfs-server
& tried again.
L2 read misses are the most costly issue there and 83% of these misses are in the dynamic linker. 77% are caused by symbol lookup for relocation and runtime resolving. 12% L2read misses for elf_hash buckets 14% L2read misses for walking the elf_hash chain 24% L2read misses for looking up the symbol entry strcmp: 23% L2read misses for comparing symbol name ... Solving the L2 cache thrashing would also benefit the cold performance considerably because a lot of the page faults there would not happen.
<Oooluver> <Oooluver> Hi9 Michael <Oooluver> Do you know anything about OpenOffice.org's performance? <Oooluver> Why do you blame glibc, gcc, the kernel, the phase of the moon, ad nauseum -- when there are plenty of examples of fast apps under Linux? <Oooluver> Why keep pointing the blame like a mardy infant? <Oooluver> OpenOffice.org is a vast, kludgy, overgrown, dilapidated codebase, and no amount of finger-pointing will correct that <Oooluver> When MS Office under WINE on Linux is faster than OO.o, you know you have a problem <Oooluver> I have some benchmarks here: http://benchmarks.on.nimp.org/ooo/ <Oooluver> They show MS Office load times in Windows, WINE on Linux, WINE on FreeBSD, and OOo native respectivelyWhen anonymous cowards are annoyed enough to send you personalised discouraging spam - with links to popup-bombs, something must be going right. Of course the fact that OO.o starts faster under WINE than Linux on the same machine seems not to feature. The more I read of the OO.o code, the more sense much of it makes, but its true - slower than 'ls', though
ls -R /usr
is pretty turgid.
set mark-symlinked-directories On
to my
/etc/inputrc
solved my bash tab completion problems.
There are a number of patches floating around that are intended to accelerate cold time startup of eg. the GNOME desktop, that seem attractive but are rather unhelpful for real world use
The premise of them is that if (as you mmap a shared library) you force the kernel to load it all, then you will get vastly better I/O behavior as it is linked & as the app starts up, since the mapped files (DSOs) are accessed fairly randomly. The premise is correct.
Where this all breaks down of course is that - what is optimal on a 1st / cold start (with lots of memory) is often extremely sub-optimal on a 2nd start
eg. after 2 hours of evolution use, lots of the code which is never touched will be paged out - to make space for other more live data. If we insist on paging that code back in - we have an evil situation - where now we have lots of scattered missing fragments. ie. by forcing 'everything' into memory we necessarily have to seek the missing [seldom used] pieces, seek, read them at great cost.
This phenomenon also bites OO.o where we do a similar trick, and causes pain on loaded / small memory machines on 2nd start. However - since this is in our app we can fix this.
Of course - again, only the kernel can know that this library has already been mmapped & that we don't now want to force page it all in. Only the kernel knows (during cold boot) that we have shed-loads of pristine, unused pages sitting around - and thus we should be aggressively pre-loading mmapped files. Only the kernel (ideally) knows what happened wrt. I/O last time during the execve of this app, what it mapped, and what it used. So - basically we're back to the old axiom for anyone comparing Linux with Win32 I/O performance: Linux I/O scheduling sucks - try to work around it.
Unfortunately this can't be worked around efficiently outside the kernel.
Furthermore, it is acutely unfortunate that the kernel hackers are just amazingly reluctant to provide sharp tools to examine how bad the I/O situation is. It being ~impossible to reliably simulate a cold-start without a hard re-boot. There being no quick way to drop all caches, file backed pages etc.
mincore
syscall that
could be used to determine if a shlib was mapped by someone else -
I guess it could be useful for glibc. Of course - one might want to
guess how sane the kernel will be wrt. seeks if you ask for pages
1,2,3, 5, 7,8 to be read. Either way - writing a separate
application that renders the OO.o splash seems the only way to
go here.
Old glibc: 3968, 3978, 3983 Avg: 3980 Just new glibc: 4224, 4238, 4250 Avg: 4240 [260ms slower - hmm] all -Bdirected: 2148, 2168, 2215 Avg: 2180 [1800ms faster - 45%]
before: 2.693, 2.721, 2.714 Avg: 2.709 after: 0.675, 0.679, 0.682 Avg: 0.679 [75% faster]
-U --replacepkgs
--oldpackage
it then worked fine.
Old glibc: 3968, 3978, 3983 Avg: 3980 Just new glibc: 4224, 4238, 4250 Avg: 4240 [260ms slower - hmm] many -Bdirected: 2378, 2387, 2389 Avg: 2385 [1600ms faster - 40%]
before: 2.693, 2.721, 2.714 Avg: 2.709 after: 0.970, 0.968, 0.956 Avg: 0.965 [65% faster]
NSP_Sleep(5); // try to connect to background SO, thus judge if it is ready while(0 > connect(my_sock, (struct sockaddr *)&dst_addr, sizeof(dst_addr))) ... NSP_CloseSocket(my_sock); NSP_Sleep(5);etc.
fprintf (stderr, "Is '%s' %c%c%c vague (%d)\n", symbol, symbol[0], symbol[1], symbol[2], ret);outputs:
Is 'typeinfo for BaseClass' _ZT vague (1)etc. More interestingly, after pre-processing it's still calling 'fprintf'; deep magic.
export LD_DEBUG=bindings:symbols:direct
we get:
8375: dynamic symbol index 602 from 'libbasegfx680li.so' for _ZTIN7basegfx29B2DPolyPolygonRasterConverterE 8375: dynamic symbol offset 65534 8375: vague symbol 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./soffice.bin 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./libvcl680li.so 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./libsvl680li.so 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./libsvt680li.so 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./libutl680li.so ... omit 10 other OO.o libs ... 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/usr/X11R6/lib/libSM.so.6 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/usr/X11R6/lib/libICE.so.6 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/usr/X11R6/lib/libX11.so.6 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/opt/gcc/lib/libdl.so.2 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/opt/gcc/lib/libpthread.so.0 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./libstlport_gcc.so 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/usr/lib/libstdc++.so.6 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/opt/gcc/lib/libm.so.6 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/lib/libgcc_s.so.1 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/opt/gcc/lib/libc.so.6 ... omit 5 other OO.o / system libs ... 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/lib/libz.so.1 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/usr/lib/libjpeg.so.62 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./libjvmfwk.so.3 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./libuno_salhelpergcc3.so.3 8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./libbasegfx680li.so 8375: binding file ./libbasegfx680li.so to ./libbasegfx680li.so: normal symbol `_ZTIN7basegfx29B2DPolyPolygonRasterConverterE'
8375: dynamic symbol index 525 from './libbasegfx680li.so' for _ZN7basegfx29B2DPolyPolygonRasterConverterD1Ev 8375: dynamic symbol offset 0 8375: symbol=_ZN7basegfx29B2DPolyPolygonRasterConverterD1Ev; lookup in file=./libbasegfx680li.so 8375: direct lookup ... 8375: binding file ./libbasegfx680li.so to ./libbasegfx680li.so: normal symbol `_ZN7basegfx29B2DPolyPolygonRasterConverterD1Ev'ie. 1 lookup instead of 30 (and this is early in the OO.o startup process, before many libs are loaded). Still poking at a few issues though; switched the system back; need to re-build glibc with
make install_root=/foo install
/lib/ld-linux.so <app>
is best. Added
some basic
vague symbol tagging / pruning and got something nicer:
$ readelf -y libfixup.so Direct relocations for image: Num: Index Binding Symbol 14: [0x0000] <self> _DYNAMIC 17: [0x0000] <self> _Z12simpleMethodP9BaseCla 18: [0x0000] <self> _init 19: [0xfffe] <vague> _ZTS11MyException 20: [0x0005] libc.so.6 stderr 23: [0x0002] libstdc++.so.6 __cxa_allocate_exception 42: [0xffff] <unknown> __gmon_start__
readelf -y
now showing my some nice direct linking information:
$ readelf -y libfixup.so Direct relocations for image: Num: Index Binding Symbol 12: [0x00] <unknown> _DYNAMIC 13: [0x01] libdl.so.2 dlsym 14: [0x02] libc.so.6 fprintf 15: [0x00] <unknown> __vt_fixup 16: [0x00] <unknown> _init 17: [0x02] libc.so.6 malloc 18: [0x02] libc.so.6 stderrwith a little more tweaking, it's onto the ld.so piece.
chkconfig --add spamd
+ manual start; after
much chasing discovered it's a silly internal bug. Quested for recent
evo. / snapshot build for SL10.0, no joy; bother. More ooo-build poking.
unset LIB INSTALL
seemed to cure the problem
very nicely. Wrote another LXF column.
ssh -X localhost xprop -root
dies with: X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 20 (X_GetProperty) _MOTIF_CLIP_FORMAT_ACROBAT_SELECTION Atom id in failed request: 0x25c Serial number of failed request: 11 Current serial number in output stream: 11. OTOH
ssh -Y localhost
works just as you would expect. Of course,
OO.o's gtk+ integration dies horribly in the 1st situation.
(gdb) p *pStg virtual baseclass botch (gdb)- most helpful.
$ cd /usr/lib/ooo-2.0/program $ MONO_PATH=. mono SpreadsheetSample.exe
error in rsync protocol data stream
(code12) at io.c (342)
- a neat rsync feature obviously.
Switched to wgetting individual ISOs.
xhost +SI:localhost:michael
- which is nice.
...adjust esp...
call __i686.get_pc_thunk.bx
...
__i686.get_pc_thunk.bx:
movl (%esp), %ebx
ret
and there is no in-lineable movl %eip, %ebx or somesuch.
Simon phoned - good to catch up.
movl <vtable-offset>(%eax), %edx
call *%edx
-> lazy_link_vtable_method(this, ...);
int offset = %edx - this->vtable;
*(this->vtable + offset) = lookup_plt_style_sym(
this->plt_style_syms[offset]);
call %edx
<-
Thus using the vtable itself in place of PLT like slots,
giving a cost of: a fixed invocation register, N-duplicate symbol
relocations to intialize the vtables [fixable] later, & storage
for them, & storage for
the symbol references to resolve the vtable later in place of the
original relocations. Should be backwards compatible at least.
Michael Matz warns of possible fn. pointer comparison problems -
true enough; wonder what the spec. says about that. Need to
measure the real number of vtable related relocations in OO.o
first.
cvs diff -u -D '2 days ago'
- dug on the web,
read the pitiful cvs -> svn guide, even desparate enough
to read the manual - no joy. Apparently one has to use
-r {2005-06-01} style dates NB. whitespace sensitive, not
'{ 2005-06-01 }' or any such variant.
namespace
keyword in a using namespace com::sun::star
statement,
doh.
ERROR: get_eis_id(): EIS database transaction failed. Reason: SOAP-ENV:Server.BadTargetObjectURI, Unable to resolve target object: com.sun.star.common.v110.staroffice.eis2.ChildWorkspaceDataUtils at /opt/OpenOffice/src680-m92/solenv/bin/modules/Eis.pm line 132.Ause did something to get it fixed.
X-Spam-Flag: YES
, I
wonder where the mis-configured SpamAssassin is.
uno finds my bridge if I link it into ooo/program. And I have here a backtrace from one of the odk sample programs running on mono, calling my native cli_ure glue, which calls my native bridge, which calls my managed bridge, which complains about bridge glue I haven't written yet.
The goal is to enleverage active, XML-based, Java community enhanced, meta-ldap specifications to provide mega-enhanced, goal-congruent, volenteer-driven, apache-powered, 'Open Source', WordPerfect file import.
Scripture | (post-)modern man |
---|---|
And God spoke all these words: | "listen to your inner voice - discover the truth that's in you." |
You shall have no other Gods before me | one religion is as good as another - it's just sincerity that counts |
you shall not kill | the only thing they'll understand is force - don't be a wuss, don't let anyone push you around. |
you shall not commit adultry | how can it be wrong when it feels so right ? |
you shall not steal | get serious, we're talking Business ethics, not ethics |
ucb::ContentBroker::initialize(...)
with some complex set of parameters, and add another set
of obscure regcomp command to my rdb construction. Anyhow,
getting the command-line gallery creation tool into some
nice shape: now at least creates a gallery.
cat /dev/zero > /dev/dsp
is enough to
provoke the lock-up on startup; shockingly shoddy fork code
in esdlib.c: "my second fork usage" perhaps, gdb lies wrt.
a problem in 'fork' itself, and a build with debugging
symbols doesn't fail; grr. abandoned it again.
sudo rug sa http://red-carpet.go-oo.org/ sudo rug sub ooo-680 sudo rug in OpenOffice_org2-gnomeIt looks a little like this: