g at PCCTS
(http://www.polhode.com/pccts.html) or ANTLR (http://www.antlr.org/).
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
---(end of broadcast)---
TIP 2: you can get off all lists at on
On Fri, Jan 26, 2001 at 05:06:24PM -0500, Jan Wieck wrote:
> So the crazy-temp-vacuum-cleaner on linux doesn't touch the
> sockets?
The tmpwatch program that comes with many Linux distributions will only
unlink regular files and empty directories by default.
--
Bruce Guen
here any CRC64 code?
All you need is a good 64-bit polynomial. Unfortunately, I've been
unable to find one that's been analyzed to any amount.
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
operations instead of 64, with
fewer constants). The inner MD4 loop is about 1.5 times the speed of
MD5.
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
)z;
ick = IUPDC32 (word1, ick); word1 >>= 8;
ick = IUPDC32 (word1, ick);
}
I tried loading two words at a time, starting to load the second word
well before it's used, but that didn't actually reduce the time taken.
> As Nathan remarks nearby, this is just min
per byte (from 13).
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
On Sat, Dec 09, 2000 at 06:46:23PM -0500, Tom Lane wrote:
> Bruce Guenter <[EMAIL PROTECTED]> writes:
> > The difference is likely because PA-RISC (like most other RISC
> > architectures) lack a "roll" opcode that is very prevalent in the MD5
> > algorithm.
gy)
No, it hasn't, unless you can provide us a reference to a paper showing
that. I've seen references that there are internal collisions in the
MD5 reduction function, but still no way to produce collisions on the
final digest.
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
s still significantly faster than CRC,
but is slightly slower at 100 byte blocks. For comparison, I added
RIPEMD-160, but it's far slower than any of them (twice as long as CRC).
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
On Fri, Dec 08, 2000 at 09:28:38PM -0500, Tom Lane wrote:
> Bruce Guenter <[EMAIL PROTECTED]> writes:
> >> I agree, don't send it to the whole list. But I'd like a copy.
> > Here you go.
> As near as I could tell, the test as you have it (one CRC computa
On Fri, Dec 08, 2000 at 04:30:58PM -0500, Tom Lane wrote:
> Bruce Guenter <[EMAIL PROTECTED]> writes:
> >> Are you really saying MD5 was faster than CRC-32?
> > Yes. I expect it's because the operations used in MD5 are easily
> > parallelized, and operate on
On Fri, Dec 08, 2000 at 03:38:09PM -0500, Tom Lane wrote:
> Bruce Guenter <[EMAIL PROTECTED]> writes:
> > MD5 is a cryptographic hash, which means (AFAIK) that ideally it is
> > impossible to produce a collision using any other method than brute
> > force attempts.
>
ngerprint. As you've mentioned, it doesn't
have the guarantees against burst errors that a CRC would have, but it
does have as good as random collision avoidance over any random data
corruption. At least, that's what the author claims. My math isn't
nearly good enough to v
ookup, and operates on
single bytes.
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
e an
unrolled inner loop). These were compiled with -O6 with egcs 1.1.2.
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
On Fri, Dec 08, 2000 at 01:58:12PM -0500, Tom Lane wrote:
> Bruce Guenter <[EMAIL PROTECTED]> writes:
> > ... Taking an
> > arbitrary 32 bits of a MD5 would likely be less collision prone than
> > using a 32-bit CRC, and it appears faster as well.
>
> ... but th
d likely be less collision prone than
using a 32-bit CRC, and it appears faster as well.
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
eferring to the case where the drive loses power in mid-write?
That is solved by either arranging for the markers to always be placed
at the start of a block, or by plugging in a UPS.
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
quate level of confidence in the event of a crash, then
I'll be satisfied, but don't call it a guarantee.
Them's small nits we're picking at, though.
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
On Wed, Dec 06, 2000 at 11:08:00AM -0800, Nathan Myers wrote:
> On Wed, Dec 06, 2000 at 11:49:10AM -0600, Bruce Guenter wrote:
> > On Wed, Dec 06, 2000 at 11:15:26AM -0500, Tom Lane wrote:
> > > How exactly *do* we determine where the end of the valid log data is,
> > &g
On Wed, Dec 06, 2000 at 11:13:33PM +, Daniele Orlandi wrote:
> Bruce Guenter wrote:
> > - Assume that a CRC is a guarantee. A CRC would be a good addition to
> > help ensure the data wasn't broken by flakey drive firmware, but
> > doesn't guarante
Assume that a CRC is a guarantee. A CRC would be a good addition to
help ensure the data wasn't broken by flakey drive firmware, but
doesn't guarantee consistency.
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
pre-cache catalog information for backends, however (see
> my post elsewhere in this thread).
Would that pre-cached data not be placed in a SHM segment? Such
segments don't do COW, so this would be a non-issue.
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
d switch time to be slightly lower than that, and context
switches between processes with large VMs would be much larger just due
to the cost of reloading the page tables.
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
al for the very many clients
>case
> (like > 3000).
Why do you believe this? In the "classical" thread implementation, each
process would get the same amount of CPU, no matter how many threads was
running in it. That would mean that many parallel processes would get
more CPU
s the cost for
doing the thread is constant. So, the cost of marking the pages as COW
is quite significant (using those numbers, 73us/MB).
So, forking a process with lots of data is expensive. However, most of
the PostgreSQL data is in a SysV IPC shared memory segment, which
shouldn't affect
hread would
grow by a few K, compared to 400K for processes). I'm simply arguing
that the differences don't appear to be significant compared to the
other costs involved.
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
er than being buzzword compliant?
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
small partitions and 4K otherwise. IIRC,
reiserfs uses 4K blocks in a tree structure that includes tail merging
which makes the question of block size tricky. Linux 2.3.x passes all
file I/O through its page cache, which deals in 4K pages on most 32-bit
architectures.
--
Bruce Guenter <[EMAIL
sensitive query data flows in the clear?
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
30 matches
Mail list logo
