Re: [boost] Boost.Chain over at Github

Subject: Re: [boost] Boost.Chain over at Github
From: Gruenke, Matt (mgruenke_at_[hidden])
Date: 2011-03-21 07:15:36

I think scatter/gather support is the only feature I've seen discussed
that's not supported by std::rope (I only looked at GCC's, but it seems
to support sharing of common substrings).  And if you don't need fast
concatenation (i.e. due to sharing), then you could use a const
std::dequeue.  So, unless I'm missing something, I think the question is
pretty much down to the value of scatter/gather I/O.

 

Now, I'm skeptical about the real-world benefits of scatter/gather I/O,
over simply copying into a contiguous temporary buffer.  It turns out
GNU's libc will even do this automatically and transparently, if you
exceed the I/O vector length limits of the kernel.  RAM is just so much
faster than even 10 Gig ethernet and SSDs.  And since L3 cache is bigger
than typical socket buffer sizes, you'll often find that emulating
scatter/gather in userspace is essentially free.  It wasn't always this
way, but I'd argue that scatter/gather I/O something of an anachronism -
it just isn't worth the trouble, any more.

 

Does anyone know of any recent benchmarks on scatter/gather I/O?  If I'm
wrong, I'd like to know it.  I did a quick search, but came up
empty-handed.  I saw something on LKML that seemed to compare it to a
sequence of synchronous reads/writes to a file with O_SYNC, but I'm
talking about replacing it with a copy + single read/write.  I'm
guessing you'd have to use a ramdisk for the difference to be
measurable.

 

 

Speaking of benchmarks, I ran across an old benchmark of GCC's
std::string vs. STLport's std::string & std::rope.  I don't know if the
results are still relevant, but it has some string benchmarking code you
could reuse (I think someone mentioned benchmarking it against other
strings, earlier in the thread).

 

    http://complement.sourceforge.net/compare.pdf

 

 

Matt

 

 

________________________________

From: boost-bounces_at_[hidden] on behalf of Mathias Gaunard
Sent: Fri 3/18/2011 6:37 AM
To: boost_at_[hidden]
Subject: Re: [boost] Boost.Chain over at Github

On 18/03/2011 03:49, Dean Michael Berris wrote:

> That's fine, I deal with lots of network I/O as part of the HTTP
> implementation in cpp-netlib and it would be really good if I can step
> away from std::string from the internals to support larger strings
> without having to induce too much fragmentation when concatenating
> strings. The intention is to have suitably efficient (not necessarily
> optimal) string representations for code that need to deal with both
> small and potentially huge strings.

Then you need a string which layout is compatible with the vectored I/O
API provided by the system (readv/writev on POSIX,
ReadFileScatter/WriteFileGather on Win32).

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost