FONDERIE VITERBESI a Progetto Fuoco
www.startup-italia.it [demime 1.01d removed an attachment of type application/octet-stream which had a name of FV_Progetto Fuoco_rif Start Up.pdf]
Re: vmmap replacement -- please test
Hi, Just to prove my point that vmmap testing is still relevant: today a bug got found and fixed, where grepping a 1.7GB file on i386 tripped an assertion (I love assertions). This brings the latest versions to: http://www.stack.nl/~ariane/vmmap_sys.diff.65 (apply against /usr/src/sys) http://www.stack.nl/~ariane/vmmap_userland.diff.30 (apply against /usr/src) Testing is still welcome. :) -- Ariane
Minor morse(6) patch
Make the lookup tables const.
Index: morse.c
===
RCS file: /cvs/src/games/morse/morse.c,v
retrieving revision 1.14
diff -u -r1.14 morse.c
--- morse.c 27 Oct 2009 23:59:26 - 1.14
+++ morse.c 18 Feb 2012 16:47:27 -
@@ -35,7 +35,7 @@
#include string.h
#include unistd.h
-static char
+static const char
*digit[] = {
-,
.,
@@ -80,7 +80,9 @@
struct punc {
char c;
char *morse;
-} other[] = {
+};
+
+static const struct punc other[] = {
{ ',', --..-- },
{ '.', .-.-.- },
{ '?', ..--.. },
@@ -100,8 +102,8 @@
};
void morse(int);
-void decode(char *);
-void show(char *);
+void decode(const char *);
+void show(const char *);
static int sflag = 0;
static int dflag = 0;
@@ -206,7 +208,7 @@
}
void
-decode(char *s)
+decode(const char *s)
{
int i;
@@ -235,7 +237,7 @@
void
-show(char *s)
+show(const char *s)
{
if (sflag)
printf( %s, s);
Fabricación de Estructuras Metálicas en general. publicidad bo neb
[demime 1.01d removed an attachment of type image/jpeg which had a name of nhollejuelo.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of ccandilazo.jpg]
Re: ksh(1): encapsulate hashtable iteration usage
Steffen Daode Nurpmeso wrote [2012-02-15 14:55+0100]:
the patch below localizes access of struct table internals to
table.c by using the ktwalk()/ktnext() interface from proto.h
instead of doing handcrafted table iterations.
Yes it was wrong because it didn't take the flags into account
correctly.
This new version offers an additional field in struct tstate which
defaults to DEFINED but can be overwritten by users to the desired
flags.
Surely a useful change regardless of possibly turning over to
a node-based hashmap approach.
I still think so.
This patch also includes the following:
ktinit() shouldn't expect pow2 size requests..
It is an implementation detail that table.array is pow2 spaced,
so let callers simply request the sizes they want, and take care
of the adjustment internally.
The diff can be applied with or without your patch already
included. It passes this:
#!/bin/sh
KSH=obj/ksh
max=24000
booogie() {
local i=0
while [[ $i -le $max ]]; do
eval X${i}=yes
i=$(($i + 1))
done
i=0
while test $i -lt $max; do
test $((i 1)) -eq 0 eval unset X${i}
i=$((i + 1))
done
i=0
while test $i -lt $max; do
test $((i 1)) -eq 0 eval X${i}=yes
i=$((i + 1))
done
i=0
while test $i -lt $max; do
test $((i 1)) -ne 0 eval unset X${i}
i=$((i + 1))
done
i=0
while test $i -lt $max; do
test $((i 1)) -eq 0 eval unset X${i}
i=$((i + 1))
done
}
time booogie
time booogie
time booogie
So sorry for the first patch, it has been sent too fast!
About the node-based hashmap.
I tell nothing new.
The problem of associative tables is of course the distribution of
the keys, which typically ends up like so:
tstats(20a601228=var.c:newblock:vars)
* Overview
- Array capacity : 4096
- Buckets (K/V pairs): 21067
- Next grow : 32768 buckets
* Stats
- Accesses : 199655
- Lookups: 199653
- Hits with !DEFINED : 21000
- Direct hits: 106478
- Bucket resorts : 40545
- Array resizes : 10
* Array index statistics
- Empty indices: 99
- Indices with multiple buckets: 3759
- Buckets per index, maximum : 12
[Don't trust the following two]
- Buckets per index average : 5 (ideal distribution)
- Buckets per index, average : 5 (real distribution)
* Index overview (index / buckets)
0/ 5 1/ 4 2/ 4 3/ 4 4/ 4 5/ 6 6/ 7
7/ 7 8/ 7 9/ 710/ 711/ 612/ 513/ 4
14/ 315/ 116/ 017/ 018/ 019/ 120/ 2
[.]
105/ 8 106/ 8 107/ 8 108/ 7 109/ 6 110/ 5 111/ 3
112/ 2 113/ 1 114/ 0 115/ 1 116/ 1 117/ 2 118/ 4
119/ 5 120/ 6 121/ 7 122/ 8 123/ 9 124/ 9 125/ 8
[.]
910/ 1 911/ 0 912/ 0 913/ 2 914/ 3 915/ 4 916/ 5
917/ 7 918/ 9 919/10 920/10 921/10 922/10 923/ 8
924/ 7 925/ 6 926/ 5 927/ 3 928/ 2 929/ 2 930/ 3
with even worser distributions for arrays of 1024 and 2048 slots;
maybe a mathematician can tell you why this is so, i'm not the one.
The problems of using non-node based, i.e., linear hashtables is
thus of course that heaps can unite; e.g., the indexes 919 - 922
contain 40 struct tbl* entries which in the worst case had to be
all checked to find the desired one.
And the only way to ease that problem is to reduce the load
factor, i.e., to place fewer entries in the array before that is
resized, but which necessarily enlargens the array.
And that enlargement must be power-of-two spaced:
RESIZE: old-nsize=8192, new=16384 = 131072; new-free:11468
RESIZE: old-nsize=16384, new=32768 = 262144; new-free:22937
Node-based hashmaps, on the other hand, split up such heaps;
you access the array once and then do a list walk.
In the above example the worst-case is thus 10 node walks.
Bucket resorting can also be a good thing, as you can see above
(without resorting there are 8910 direct hits), but it surely
can result in the opposite, dependent on the actual use-case.
The best thing about node-based hashmaps is however that you can
reduce the load factor; in the above log extract the map has
a load factor of 800% (32768 / 4096). E.g., whereas the linear
one requires 261144 bytes of continuous memory, the node one
only requires 32768.
Well and after these well-known basics some more numbers.
If i run the above test in a VM with (the below patch and Chris
Toreks hash plus applied) i get these:
2. 0m6.63s real 0m6.51s user 0m0.07s system
3. 0m6.65s real 0m6.63s user 0m0.02s system
For the node-based with 2==400% to 256 slots, then 3==800% load:
2. 0m7.46s real 0m7.32s user 0m0.11s system
3.
PF-MIB for snmpd
Hi, Here's the patch to bring the PF-MIB to snmpd. It provides the same OIDs that my patches for net-snmp provide. Some differences: - This implementation uses the OpenBSD enterprise number (30155) instead of a private/reserved number - Many of the OID names have been changed to make them less ambiguous and to avoid current or future naming conflicts (eg, running changed to pfRunning) I've been running this on a couple of boxes with no issues. The diff is pretty long so I'm only going to post a link. Please test. http://www.packetmischief.ca/files/openbsd/patches/snmpd.pf.diff .joel
Re: PF-MIB for snmpd
Looks like there's an issue pulling the diff with lynx or curl. If you use Firefox or Chrome it seems to work fine. Not sure what's going on. The diff is also on dropbox now. http://dl.dropbox.com/u/34631638/snmpd.pf.diff On Sat, Feb 18, 2012 at 2:34 PM, Joel Knight knight.j...@gmail.com wrote: Hi, Here's the patch to bring the PF-MIB to snmpd. It provides the same OIDs that my patches for net-snmp provide. Some differences: - This implementation uses the OpenBSD enterprise number (30155) instead of a private/reserved number - Many of the OID names have been changed to make them less ambiguous and to avoid current or future naming conflicts (eg, running changed to pfRunning) I've been running this on a couple of boxes with no issues. The diff is pretty long so I'm only going to post a link. Please test. http://www.packetmischief.ca/files/openbsd/patches/snmpd.pf.diff .joel
Re: PF-MIB for snmpd
Joel Knight knight.j...@gmail.com writes: Looks like there's an issue pulling the diff with lynx or curl. If you use Firefox or Chrome it seems to work fine. Not sure what's going on. looks clean when fetched with ftp(1) as well, didn't actually try applying though. it's against a recent -current, right? - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: PF-MIB for snmpd
On Sat, Feb 18, 2012 at 5:02 PM, Peter N. M. Hansteen pe...@bsdly.net wrote: Joel Knight knight.j...@gmail.com writes: Looks like there's an issue pulling the diff with lynx or curl. If you use Firefox or Chrome it seems to work fine. Not sure what's going on. looks clean when fetched with ftp(1) as well, didn't actually try applying though. it's against a recent -current, right? Yes, you'll need a recent checkout of -current for this to apply cleanly. .joel
Re: ksh(1): encapsulate hashtable iteration usage
On Sat, Feb 18, 2012 at 09:18:29PM +0100, Steffen Daode Nurpmeso wrote: [snip] while I did graduate on a theoretical computer science subject myself I think this alternate hash table stuff is all overkill for ksh. A typical shell instance has very little vars. Added to that, the ksh code is tricky, so I'd resist big changes. -Otto
