Google Groups Home
Help | Sign in
wide-finder
Home
+ new post
Pages
Files
About this group
Join this group
More results (real 7m02s) and ? about I/O performance of the T2000
Options
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
   3 messages - Collapse all
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
Mauricio Fernandez  
View profile
  More options Jun 10, 9:27 pm
From: Mauricio Fernandez <m...@acm.org>
Date: Wed, 11 Jun 2008 03:27:45 +0200
Local: Tues, Jun 10 2008 9:27 pm
Subject: More results (real 7m02s) and ? about I/O performance of the T2000
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
The small changes I referred to in my previous post were successful, and I got
these times in a lucky run yesterday:

wf2-multicore2.ml (OCaml), 135 + ~20 LoCs

real    7m1.812s
user    129m0.202s
sys     14m43.638s

The latency of the merge stage is masked by processing the results as they
arrive (the workers perform at different speeds).

Now, regarding I/O...  Tim got a 150MB/s sequential read speed with 76% CPU
usage in Bonnie[1], but I'm getting a mere ~100 MB/s when reading O.all
sequentially...  with mmap(!).

When reading O.10m (hot cache, no disk activity, as verified with iostat) with
mmap, I get ~120MB/s in the first run, ~440MB/s in the second one; in both
cases 100% of one core is used. This is all quite strange.

[1] I took a look at the bonnie-64-read-only tree; there's nothing fancy in
the "Reading intelligently phase", it just gets (up to) 16384-byte chunks with
read(2).
--
Mauricio Fernandez  -   http://eigenclass.org


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Tim Bray  
View profile
  More options Jun 10, 10:48 pm
From: "Tim Bray" <timb...@gmail.com>
Date: Tue, 10 Jun 2008 19:48:03 -0700
Local: Tues, Jun 10 2008 10:48 pm
Subject: Re: More results (real 7m02s) and ? about I/O performance of the T2000
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
Mauricio, you going to update the results page?  And maybe update the
thread it points to?  Or even better, write a considered blog entry
talking about all this stuff and link to that?   -T


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Eric Wong  
View profile
  More options Jun 11, 1:33 am
From: Eric Wong <normalper...@gmail.com>
Date: Tue, 10 Jun 2008 22:33:18 -0700 (PDT)
Local: Wed, Jun 11 2008 1:33 am
Subject: Re: More results (real 7m02s) and ? about I/O performance of the T2000
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
On Jun 10, 6:27 pm, Mauricio Fernandez <m...@acm.org> wrote:

> The small changes I referred to in my previous post were successful, and I got
> these times in a lucky run yesterday:

> wf2-multicore2.ml (OCaml), 135 + ~20 LoCs

> real    7m1.812s
> user    129m0.202s
> sys     14m43.638s

Wow!  Running mine with an improved reduce phase now :)

> The latency of the merge stage is masked by processing the results as they
> arrive (the workers perform at different speeds).

> Now, regarding I/O...  Tim got a 150MB/s sequential read speed with 76% CPU
> usage in Bonnie[1], but I'm getting a mere ~100 MB/s when reading O.all
> sequentially...  with mmap(!).

I didn't get very good results with mmap (I was using MAP_PRIVATE,
maybe
MAP_SHARED is less VM-intensive?).   I was using madvise
MADV_SEQUENTIAL too.

I'm also feed my mawks through (what appears to be) a 4K pipe buffer
and I
can't get the load average even >16 right now.  At least that's the
pipe
buffer size bash/ksh are reporting (when they were compiled).

Too bad {posix_,}fadvise doesn't appear to be an option on Solaris,
and
sendfile{,v} + socketpair doesn't work either.  I'll try using
socketpair()
again in a bit, too; since it lets me pick bigger buffers than pipe().


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2008 Google