On Thu, 2015-05-14 at 07:42 +, Poul-Henning Kamp wrote:
In message 20150514072155.gt37...@funkthat.com, John-Mark Gurney writes:
Since you apprently missed my original reply, I said that we shouldn't
abuse BUFSIZ for this work, and that it should be changed in mdXhl.c...
Say
On 5/14/15 2:23 AM, Garrett Cooper wrote:
On May 14, 2015, at 1:06, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message 20150514075316.gy37...@funkthat.com, John-Mark Gurney writes:
Poul-Henning Kamp wrote this message on Thu, May 14, 2015 at 07:42 +:
In message
On Thu, May 14, 2015 at 08:53:05AM -0600, Ian Lepore wrote:
At least I'm inclined to ponder it. Apparently nobody else is. People
running servers with more GB of ram than grains of sand on the beach
won't care about things like 64k buffers used by /bin/sh to read a line
of text, and all the
In message 5554b8d6.1010...@mu.org, Alfred Perlstein writes:
Shouldn't most of these be using st.st_blksize ?
We had a long discussion about that back when GEOM was young and the
conclusionis that st_blksize doesn't tell you anything useful
and generally does the wrong thing, in
In message 72720ea2-c251-40b9-9ec0-702c07d5e...@gmail.com, Garrett Cooper
writes:
Until performance has been characterized on 32-bit vs
64-bit architectures, blanket changing a value doesn't make sense.
First time I saw benchmarks which showed improved performance
from a larger
In message 1431615185.1221.57.ca...@freebsd.org, Ian Lepore writes:
I think we've got differing interpretations of what BUFSIZ is for.
IMO, the one correct use of BUFSIZ outside of libc is if you are going
to call setbuf() the buffer you pass must be BUFSIZ bytes long.
Over the years,
Ian Lepore wrote this message on Wed, May 13, 2015 at 12:47 -0600:
On Wed, 2015-05-13 at 11:13 -0700, John-Mark Gurney wrote:
Adrian Chadd wrote this message on Wed, May 13, 2015 at 08:34 -0700:
The reason I ask about why is it faster? is because for embedded-y
things with low RAM we may
David Chisnall wrote this message on Wed, May 13, 2015 at 09:27 +0100:
On 13 May 2015, at 09:03, John-Mark Gurney j...@funkthat.com wrote:
Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
In message 20150512032307.gp37...@funkthat.com, John-Mark Gurney
Poul-Henning Kamp wrote this message on Thu, May 14, 2015 at 07:42 +:
In message 20150514072155.gt37...@funkthat.com, John-Mark Gurney writes:
Since you apprently missed my original reply, I said that we shouldn't
abuse BUFSIZ for this work, and that it should be changed in
In message 20150514075316.gy37...@funkthat.com, John-Mark Gurney writes:
Poul-Henning Kamp wrote this message on Thu, May 14, 2015 at 07:42 +:
In message 20150514072155.gt37...@funkthat.com, John-Mark Gurney writes:
Since you apprently missed my original reply, I said
In message 20150514072155.gt37...@funkthat.com, John-Mark Gurney writes:
Since you apprently missed my original reply, I said that we shouldn't
abuse BUFSIZ for this work, and that it should be changed in mdXhl.c...
Say what ?
BUFSIZ is used entirely appropriately in MDXFileChunk():
On May 14, 2015, at 1:06, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message 20150514075316.gy37...@funkthat.com, John-Mark Gurney writes:
Poul-Henning Kamp wrote this message on Thu, May 14, 2015 at 07:42 +:
In message 20150514072155.gt37...@funkthat.com,
In message 1431542835.1221.30.ca...@freebsd.org, Ian Lepore writes:
On Wed, 2015-05-13 at 11:13 -0700, John-Mark Gurney wrote:
As I've already pointed out, BUFSIZ appears in the
base code over 2000 times. Where is the analysis of the impact an 8x
change is going to have on all those
On May 14, 2015, at 1:01, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message 1431542835.1221.30.ca...@freebsd.org, Ian Lepore writes:
On Wed, 2015-05-13 at 11:13 -0700, John-Mark Gurney wrote:
As I've already pointed out, BUFSIZ appears in the
base code over 2000 times.
On 05/13/15 10:27, David Chisnall wrote:
On 13 May 2015, at 09:03, John-Mark Gurney j...@funkthat.com wrote:
Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
In message 20150512032307.gp37...@funkthat.com, John-Mark Gurney writes:
Also, you'd probably see
On 13 May 2015, at 09:03, John-Mark Gurney j...@funkthat.com wrote:
Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
In message 20150512032307.gp37...@funkthat.com, John-Mark Gurney writes:
Also, you'd probably see even better performance by increasing the
On Wed, 2015-05-13 at 11:13 -0700, John-Mark Gurney wrote:
Adrian Chadd wrote this message on Wed, May 13, 2015 at 08:34 -0700:
The reason I ask about why is it faster? is because for embedded-y
things with low RAM we may not want that to happen due to memory
constraints. However, we may
On Wed, 2015-05-13 at 10:35 +0200, Hans Petter Selasky wrote:
On 05/13/15 10:27, David Chisnall wrote:
On 13 May 2015, at 09:03, John-Mark Gurney j...@funkthat.com wrote:
Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
In message
[snip]
The reason I ask about why is it faster? is because for embedded-y
things with low RAM we may not want that to happen due to memory
constraints. However, we may actually want to do some form of
autotuning on some platforms.
So, if it's underlying block size, maybe BUFSIZ isn't the thing
Hans Petter Selasky wrote this message on Wed, May 13, 2015 at 10:35 +0200:
On 05/13/15 10:27, David Chisnall wrote:
On 13 May 2015, at 09:03, John-Mark Gurney j...@funkthat.com wrote:
Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
In message
Adrian Chadd wrote this message on Wed, May 13, 2015 at 08:34 -0700:
The reason I ask about why is it faster? is because for embedded-y
things with low RAM we may not want that to happen due to memory
constraints. However, we may actually want to do some form of
autotuning on some platforms.
Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
In message 20150512032307.gp37...@funkthat.com, John-Mark Gurney writes:
Also, you'd probably see even better performance by increasing the
size to 64k, [...]
easy:
8K on 32bit
64k on 64bit
4k block size on the underlying device?
On 12/05/2015 00:14, Adrian Chadd wrote:
So I'm curious - why's it faster?
-adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send
In message 20150512032307.gp37...@funkthat.com, John-Mark Gurney writes:
Also, you'd probably see even better performance by increasing the
size to 64k, [...]
easy:
8K on 32bit
64k on 64bit
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org
On Tue, May 12, 2015 at 06:31:33AM +, Poul-Henning Kamp wrote:
Also, you'd probably see even better performance by increasing the
size to 64k, [...]
easy:
8K on 32bit
64k on 64bit
Need benchmarking.
May be 16K is local maximum (L1 cache-efficient).
Hi,
I would like to change the default value of BUFSIZ to 8192.
After testing various applications that uses BUFSIZ like changing it in libmd I
can often see performance improvements:
For example with md5(1):
Current BUFSIZ (1024)
0.13 real 0.04 user 0.09 sys
New BUFSIZ (8192)
So I'm curious - why's it faster?
-adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Baptiste Daroussin wrote this message on Tue, May 12, 2015 at 01:06 +0200:
I would like to change the default value of BUFSIZ to 8192.
After testing various applications that uses BUFSIZ like changing it in libmd
I
can often see performance improvements:
For example with md5(1):
Current
28 matches
Mail list logo
