In message <[EMAIL PROTECTED]> "Aleksandr A.Babaylov" writes:
: > This is one reason I have TMPDIR set to "." when I'm running as me.
: ...and lose a lot of files to delete...
My sources are cvs controlled, and a cvs update -n tells me what to
delete when gcc doesn't do it for me. And when I'm n
Warner Losh writes:
> In message <[EMAIL PROTECTED]> Kris
>Kennaway writes:
> : (incidentally, another reason to use -pipe is that the above filenames are
> : predictable and probably handled insecurely so that another user can cause
> : any of your files to be overwritten when you compile someth
In message <[EMAIL PROTECTED]> Kris
Kennaway writes:
: (incidentally, another reason to use -pipe is that the above filenames are
: predictable and probably handled insecurely so that another user can cause
: any of your files to be overwritten when you compile something. This is
: on my list of
Kris Kennaway writes:
> On Fri, 12 May 2000, Koster, K.J. wrote:
>
> > Unless this has been changed from 3.4 to 4.0, gcc defaults to /var/tmp. I
> > never understood why, and the gcc manual page claims that it's /tmp (I
> > think). MFS users, synchronize your TMPDIR variables ... now. :-)
>
> It
Kris Kennaway wrote:
>
> On Mon, 24 Apr 2000, Kent Stewart wrote:
>
> > This is what I see on a buildworld with 4.0-Stable
> >
> > Modified /etc/make.conf and commented out CFLAGS= -Os -pipe
> > 3707.4u 799.6s 1:35:52.46 78.3% 1374+1477k 56974+173232io 2337pf+0w
> > 3693.9u 800.5s 1:29:45.73 8
On Fri, 12 May 2000, Koster, K.J. wrote:
> Unless this has been changed from 3.4 to 4.0, gcc defaults to /var/tmp. I
> never understood why, and the gcc manual page claims that it's /tmp (I
> think). MFS users, synchronize your TMPDIR variables ... now. :-)
It did.
Compiling a simple test progr
>
> Leaving out -pipe would be slower still, because the
> compiler does data passing using temporary files in /tmp
> instead of via a pipe.
>
Unless this has been changed from 3.4 to 4.0, gcc defaults to /var/tmp. I
never understood why, and the gcc manual page claims that it's /tmp (I
think).
On Mon, 24 Apr 2000, Kent Stewart wrote:
> This is what I see on a buildworld with 4.0-Stable
>
> Modified /etc/make.conf and commented out CFLAGS= -Os -pipe
> 3707.4u 799.6s 1:35:52.46 78.3% 1374+1477k 56974+173232io 2337pf+0w
> 3693.9u 800.5s 1:29:45.73 83.4% 1375+1477k 55201+173224io 2160pf+0
Dan Nelson wrote:
>
> In the last episode (Apr 26), Kent Stewart said:
> > I just noticed that mine isn't showing "Tagged Queueing Enabled" is
> > that something I can set? The adapter is an Adaptec 2940uw.
> >
> > da0 at ahc0 bus 0 target 4 lun 0
> > da0: Fixed Direct Access SCSI-2 device
> >
> > A modern hard disk can do 10-30 MBytes/sec to/from the platter, assuming
> > no seeks. But the moment it needs to seek the performance drops
> > drastically ... generally down to 1-5 MBytes/sec.
>
> I haven't seen any 30MB/s. The 10K LVD IBM's were just about the
> fastest at 20MB/s co
:In the last episode (Apr 26), Kent Stewart said:
:> I just noticed that mine isn't showing "Tagged Queueing Enabled" is
:> that something I can set? The adapter is an Adaptec 2940uw.
:>
:> da0 at ahc0 bus 0 target 4 lun 0
:> da0: Fixed Direct Access SCSI-2 device
:> da0: 40.000MB/s transfers (
In the last episode (Apr 26), Kent Stewart said:
> I just noticed that mine isn't showing "Tagged Queueing Enabled" is
> that something I can set? The adapter is an Adaptec 2940uw.
>
> da0 at ahc0 bus 0 target 4 lun 0
> da0: Fixed Direct Access SCSI-2 device
> da0: 40.000MB/s transfers (20.000MH
Matthew Dillon wrote:
>
> The standard PCI bus can do 130 MBytes/sec. Even with overhead issues
> (setup for a DMA burst) it can still do 100 MBytes/sec.
But that depends on what is also going on at the same time. There are
three other cards in my PCI bus. You can eliminate one becaus
The standard PCI bus can do 130 MBytes/sec. Even with overhead issues
(setup for a DMA burst) it can still do 100 MBytes/sec.
A standard SCSI controller can do 40, 80, and now even 160 MBytes/sec
over the wire - standard copper cabling w/ LVD connectors (example
below).
Narvi wrote:
>
> On Sat, 22 Apr 2000, Matthew Dillon wrote:
>
> [snip]
>
> > disk itself is probably the bottleneck. Disk writes tend to be
> > somewhat slower then disk reads and the seeking alone (between source
> > file and destination file), even when using a large block size
On Sat, 22 Apr 2000, Matthew Dillon wrote:
[snip]
> disk itself is probably the bottleneck. Disk writes tend to be
> somewhat slower then disk reads and the seeking alone (between source
> file and destination file), even when using a large block size,
> will reduce performanc
George Cox wrote:
>
> On 24/04 00:08, Christian Weisgerber wrote:
>
> > Hasn't O'Brien recently said that in fact "-pipe" is already the default
> > for our cc, so explicitly specifying the option doesn't do anything?
>
> Try compiling a 'hello world' program with and without the '-pipe' opti
On 24/04 00:08, Christian Weisgerber wrote:
> Hasn't O'Brien recently said that in fact "-pipe" is already the default
> for our cc, so explicitly specifying the option doesn't do anything?
Try compiling a 'hello world' program with and without the '-pipe' option
but with '-v' switched on in bot
:Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
:> -pipe makes a significant difference since without it every source
:> file being compiled creates several files in /tmp.
:
:Hasn't O'Brien recently said that in fact "-pipe" is already the
:default for our cc, so explicitly specifying the op
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> -pipe makes a significant difference since without it every source
> file being compiled creates several files in /tmp.
Hasn't O'Brien recently said that in fact "-pipe" is already the
default for our cc, so explicitly specifying the option doe
:>
:> I don't know what your setup is, Kent, but when I do a buildworld
:> my system is 95% cpu bound, with virtual no idle time at all. It's
:> all going to the buildworld. On both 3.x and 4.x.
:
:It is on 4.x but it wasn't on 3.4. At least, seti was taking time that
:it shouldn't
Matthew Dillon wrote:
>
> :The bugs were fixed in 4.0? What I saw was far too much cpu going to
> :setiathome on 3.4. Seti hardly ran on 4.0. I don't have quantities
> :because I have only noticed the really large increase in cpu time
> :required to build 4.0. The wall clock time on a buildworld
:The bugs were fixed in 4.0? What I saw was far too much cpu going to
:setiathome on 3.4. Seti hardly ran on 4.0. I don't have quantities
:because I have only noticed the really large increase in cpu time
:required to build 4.0. The wall clock time on a buildworld hardly
:changed (55-60 minutes)
Matthew Dillon wrote:
>
> :You are right but that is because I haven't started keeping record on
> :4.0-Stable and we were comparing apples and oranges. A buildworld of
> :3.4-Stable required around 2000u seconds using gcc-2.8.2 on my system.
> :Setiathome, which is running at a nice of 19, sti
:You are right but that is because I haven't started keeping record on
:4.0-Stable and we were comparing apples and oranges. A buildworld of
:3.4-Stable required around 2000u seconds using gcc-2.8.2 on my system.
:Setiathome, which is running at a nice of 19, still consumed 90% of
:the cpu. A buil
Matthew Dillon wrote:
>
> :I tested build worlds where I created my /usr/obj on one controller
> :and left the /usr/src on a different controller. The buildworlds are
> :pretty much I/O bound. They ran faster but not that much faster when
>
> Buildworlds are NOT I/O bound. They are *CPU*
On Sat, 22 Apr 2000, Michael Bacarella wrote:
> It seems silly to implement something as trivial and straightforward as
> copying a file in userland. The process designated to copy a file just
> sits in a tight loop invoking the read()/write() syscalls
> repeatedly. Since this operation is alread
:
:I made some tests on my FreeBSD machine. In the past, double buffering
:only helps if you have concurrent I/O capability. You only have that
:if you have dual access to each I/O device (HD) via different data
:channels. We don't have that capability on PC's. The typical drives
:that we purchase
:Err... I think what Alfred (should have) meant was that you should mmap
:the source file and madvise it MADV_SEQUENTIAL, then write() to the new
:file directly from that. How bad do you foresee performance being then?
:
:--
: Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
Gérard Roudier wrote:
>
> On Sat, 22 Apr 2000, Matthew Dillon wrote:
>
> > :> :extend (using truncate) and then mmap() the destination file, then
> > :> :read() directly into the mmap()'d portion.
> > :> :
> > :> :I'd like to see what numbers you get. :)
> > :
> > :> read + write is a bett
On Sat, 22 Apr 2000, Matthew Dillon wrote:
> :> :extend (using truncate) and then mmap() the destination file, then
> :> :read() directly into the mmap()'d portion.
> :> :
> :> :I'd like to see what numbers you get. :)
> :
> :> read + write is a better way to do it. It is still possible to
On Sat, 22 Apr 2000, Matthew Dillon wrote:
>
> :extend (using truncate) and then mmap() the destination file, then
> :read() directly into the mmap()'d portion.
> :
> :I'd like to see what numbers you get. :)
> :
> :--
> :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
>
> Proba
Matthew Dillon wrote:
>
> :
> :
> :> :extend (using truncate) and then mmap() the destination file, then
> :> :read() directly into the mmap()'d portion.
> :> :
> :> :I'd like to see what numbers you get. :)
> :
> :> read + write is a better way to do it. It is still possible to
> :> d
:
:
:> :extend (using truncate) and then mmap() the destination file, then
:> :read() directly into the mmap()'d portion.
:> :
:> :I'd like to see what numbers you get. :)
:
:> read + write is a better way to do it. It is still possible to
:> double buffer. In this case simply create a
> :extend (using truncate) and then mmap() the destination file, then
> :read() directly into the mmap()'d portion.
> :
> :I'd like to see what numbers you get. :)
> read + write is a better way to do it. It is still possible to
> double buffer. In this case simply create a small anony
:extend (using truncate) and then mmap() the destination file, then
:read() directly into the mmap()'d portion.
:
:I'd like to see what numbers you get. :)
:
:--
:-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Probably not so good considering the number of faults that will
b
* Kevin Day <[EMAIL PROTECTED]> [000421 20:24] wrote:
>
> Has anyone attempted to create a double buffered version of cp(1)? When
> copying from one disk to another, disk activity seems to ping-pong between
> the two, rather than keeping both active at the same time.
>
> If I were to fork and do
Has anyone attempted to create a double buffered version of cp(1)? When
copying from one disk to another, disk activity seems to ping-pong between
the two, rather than keeping both active at the same time.
If I were to fork and do something similar to afio, or maybe even doing
something weird li
38 matches
Mail list logo
