Tuesday, August 4, 2015

Digest for comp.lang.c++@googlegroups.com - 25 updates in 6 topics

c.milanesi.bg@gmail.com: Aug 04 02:46PM -0700

I recently released the open source library "cpp-mmf":
https://github.com/carlomilanesi/cpp-mmf
 
It encapsulates memory-mapped files for both POSIX and Windows operating systems.
 
It has the same purpose and the same run-time speed of the "Memory-Mapped Files" Boost library, but it offers the following advantages:
* It has no dependencies on other libraries, except, of course, the operating system headers.
* It is faster to compile. Using Linux, it is about 5 times as fast to compile than using Boost.
* It generates smaller code. Using Linux, it generates a stripped program that is less than a third of the one generated using Boost.
* It has a better tutorial.
 
--
Carlo Milanesi
Melzzzzz <mel@zzzzz.com>: Aug 04 05:48PM +0200

I can't seem to find standard way, is there one?
Victor Bazarov <v.bazarov@comcast.invalid>: Aug 04 11:52AM -0400

On 8/4/2015 11:48 AM, Melzzzzz wrote:
> I can't seem to find standard way, is there one?
 
Nope. It's platform-specific, I am pretty sure.
 
V
--
I do not respond to top-posted replies, please don't ask
"Öö Tiib" <ootiib@hot.ee>: Aug 04 09:09AM -0700

On Tuesday, 4 August 2015 18:48:23 UTC+3, Melzzzzz wrote:
> I can't seem to find standard way, is there one?
 
With C++11:
 
#include <thread>
unsigned int nthreads = std::thread::hardware_concurrency();
 
Without C++11 but boost libraries available:
 
#include <boost/thread.hpp>
unsigned int nthreads = boost::thread::hardware_concurrency();
 
For old crap no C++11, no boost there are typically nonstandard
ways per each platform like 'sysctl', 'sysconf' or 'GetSystemInfo'.
Victor Bazarov <v.bazarov@comcast.invalid>: Aug 04 12:11PM -0400

On 8/4/2015 12:09 PM, Öö Tiib wrote:
 
> With C++11:
 
> #include <thread>
> unsigned int nthreads = std::thread::hardware_concurrency();
 
But that doesn't actually give the number of CPUs, does it? And the
implementation is allowed to return 0 (which isn't helpful to those who
need to know the number of CPUs)...
 
> unsigned int nthreads = boost::thread::hardware_concurrency();
 
> For old crap no C++11, no boost there are typically nonstandard
> ways per each platform like 'sysctl', 'sysconf' or 'GetSystemInfo'.
 
V
--
I do not respond to top-posted replies, please don't ask
"Öö Tiib" <ootiib@hot.ee>: Aug 04 09:43AM -0700

On Tuesday, 4 August 2015 19:12:01 UTC+3, Victor Bazarov wrote:
 
> But that doesn't actually give the number of CPUs, does it? And the
> implementation is allowed to return 0 (which isn't helpful to those who
> need to know the number of CPUs)...
 
Yes, it gives number of threads that can run concurrently and that may
be more than number of CPU-s since modern CPU can be hyperthreadable
unit. CPU becomes all more and more dim concept and so the number of
those may be is not what we actually want? If it really does return 0 then
there are the other options below.
 
Additionally all more and more C++ compilers support OpenMP and
that brings 'omp_get_num_procs' with it. It does return processors
available to the calling process at moment of calling. That may be also
something of interest for a running program.
 
Ian Collins <ian-news@hotmail.com>: Aug 05 09:12AM +1200

Victor Bazarov wrote:
 
> But that doesn't actually give the number of CPUs, does it? And the
> implementation is allowed to return 0 (which isn't helpful to those who
> need to know the number of CPUs)...
 
While true, the number returned (if it isn't zero) if probably more use
than the number of CPUs which is becoming more of a nebulous concept
these days!
 
--
Ian Collins
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 04 12:43AM +0100

On Mon, 3 Aug 2015 21:39:21 +0100
> reads. As far as I can tell they are relying on the mutex doing a
> memory order consume on acquisition, and an release on release. I'd
> prefer them to say so explicitly.
 
It's a matter of language definition. std::mutex::lock() performs an
acquire operation (not just a consume). std::mutex::unlock() performs
a release operation. No load after an acquire can migrate before
the corresponding prior release on the same mutex object. No store
prior to the release can migrate after the corresponding subsequent
acquire on that mutex. What's the point of documenting that in the
code, unless this is a custom mutex object with unusual properties (in
which case documentation would be essential)?
 
As I understand it boost::mutex does the same as standard mutexes, but
in any event the header to your post indicates you are interested in the
standard memory model rather than what boost's mutexes happen to do.
Unsurprisingly, POSIX mutexes happen to have the same semantics as
standard mutexes so it would be astonishing if boost::mutex was
different.
 
> http://en.cppreference.com/w/cpp/atomic/memory_order
 
> Does it mean any variable at all? Or is it just volatiles? Or is it
> just other atomics?
 
So far as concerns the standard memory model and standard mutexes, it
applies to anything. That is the point of a mutex. And because a mutex
unlock (unless it is a custom mutex) has release semantics, it doesn't
only apply to dependent loads.
 
Chris
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 04 12:56AM +0100

On Tue, 4 Aug 2015 00:43:40 +0100
> applies to anything. That is the point of a mutex. And because a mutex
> unlock (unless it is a custom mutex) has release semantics, it doesn't
> only apply to dependent loads.
 
I should qualify that by saying that you have quoted from documentation
on std::memory_order. In relation to atomic variables, the
documentation refers to dependent loads relating to a memory operation
on the same atomic variable. However, your post was concerned with
mutexes, about which I responded.
 
Chris
Paavo Helde <myfirstname@osa.pri.ee>: Aug 03 11:22PM -0500

Vir Campestris <vir.campestris@invalid.invalid> wrote in
> http://en.cppreference.com/w/cpp/atomic/memory_order
 
> Does it mean any variable at all? Or is it just volatiles? Or is it just
> other atomics?
 
"Volatile" has next to nothing to do with multithreading. It's meant for
things like memory-mapped hardware registers and signal handling and brief
googling suggests that it might not be sufficient even for these purposes
nowadays.
 
It's true that volatiles can be used to mimick atomics to some extent on
some platforms, but as we now have std::atomic which is both portable and
actually guaranteed to work, one can totally forget about the volatile
keyword, at least in regard of multithreading.
 
Cheers
Paavo
Vir Campestris <vir.campestris@invalid.invalid>: Aug 04 09:38PM +0100

On 03/08/2015 21:46, Victor Bazarov wrote:
>> consume on acquisition, and an release on release. I'd prefer them to
>> say so explicitly.
 
> Who are "they"?
 
Ah. My mistake. In this case I meant the documentation; I wasn't clear.
 
 
> First off, there is a whole bunch of examples after those statements.
> Have you taken the time to read those? Do they not shed any light on
> what you need to know?
 
I did. It seems I missed some; perhaps it's easier to read them at home
in a room by myself than in the middle of an open office.
 
>> Does it mean any variable at all? Or is it just volatiles? Or is it just
>> other atomics?
 
> It means any variable, AFAICT.
 
Which is backed up by this:
 
"If an atomic store in thread A is tagged memory_order_release and an
atomic load in thread B from the same variable is tagged
memory_order_acquire, all memory writes (non-atomic and relaxed atomic)
that happened-before the atomic store from the point of view of thread
A, become visible side-effects in thread B, that is, once the atomic
load is completed, thread B is guaranteed to see everything thread A
wrote to memory."
 
Thanks
 
Andy
Vir Campestris <vir.campestris@invalid.invalid>: Aug 04 09:40PM +0100

On 04/08/2015 00:43, Chris Vine wrote:
> Unsurprisingly, POSIX mutexes happen to have the same semantics as
> standard mutexes so it would be astonishing if boost::mutex was
> different.
 
I had a good read on the Boost documentation, and couldn't see anything
that states that they perform acquires and releases. I'll assume that
they do what the standard ones are documented to do.
 
Thanks
 
Andy
Juha Nieminen <nospam@thanks.invalid>: Aug 04 08:21AM

> I think there's a place for std::string, but I use it less
> than previously. I guess it's back to the future with arrays
> of char.
 
How would an array of chars be faster than std::string? Unless you are
using a static array (or somehow reusing the same allocated array,
which becomes a bit complicated)?
 
(Also note that the major compiler implementations are moving to
short string optimization, which means that if the majority of your
strings are short, then std::string will probably be faster than
using raw C strings.)
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
"Öö Tiib" <ootiib@hot.ee>: Aug 04 08:07AM -0700

On Tuesday, 4 August 2015 11:21:29 UTC+3, Juha Nieminen wrote:
> > than previously. I guess it's back to the future with arrays
> > of char.
 
> How would an array of chars be faster than std::string?
 
Array can't but sometimes we can win a lot by using subranges of array.
 
Essentially what you wrote two posts ago: "If instead of a million individual
allocations you can perform just one, your program will become faster." ;-)
 
There are proposals about adding helpers to C++:
'string_view' from Łukasz Mendakiewicz and Herb Sutter https://isocpp.org/files/papers/N3762.html
'array_view' From Jeffrey Yasskin http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3851.pdf
 
> Unless you are
> using a static array (or somehow reusing the same allocated array,
> which becomes a bit complicated)?
 
Lot of text processing that uses 'string' will actually win same done
using 'char*'. It is because the most simple operations like usage of
'std::string::append' versus 'std::strcat' tend to be somewhat faster.
 
> short string optimization, which means that if the majority of your
> strings are short, then std::string will probably be faster than
> using raw C strings.)
 
64 bit implementation can optimize 22 chars plus trailing null
as "short". If something like 'string_view' will be added to language
as well then the last little excuse left for raw 'char*' usage in C++
is 'argv' of 'main'. ;-)
JiiPee <no@notvalid.com>: Aug 04 04:14PM +0100

On 16/07/2015 12:23, bartekltg wrote:
> cout<<fac(x);
> }
 
> ;-)
 
#include <iostream>
#include <exception>
 
constexpr long long unsafeFac(int k)
{
return (k == 0) ? 1 : k * unsafeFac(k - 1);
}
 
constexpr long long fac(int k)
{
return (k < 0 || k > 15) ? throw std::exception() : unsafeFac(k);
}
 
int main()
{
uint64_t x;
std::cin >> x;
try
{
std::cout << fac(x);
}
catch (std::exception& e)
{
std::cerr << "factorial must be [0-15] " << e.what() << '\n';
}
 
return 0;
}
woodbrian77@gmail.com: Aug 04 10:15AM -0700

On Tuesday, August 4, 2015 at 3:21:29 AM UTC-5, Juha Nieminen wrote:
 
> How would an array of chars be faster than std::string? Unless you are
> using a static array (or somehow reusing the same allocated array,
> which becomes a bit complicated)?
 
This is interesting
 
http://stackoverflow.com/questions/21946447/how-much-performance-difference-when-using-string-vs-char-array
 
> short string optimization, which means that if the majority of your
> strings are short, then std::string will probably be faster than
> using raw C strings.)
 
I think that's limited to about 20 characters.
 
Brian
Ebenezer Enterprises - "America didn't create religious liberty;
religious liberty created America." Bobby Jindal
 
http://webEbenezer.net
Bo Persson <bop@gmb.dk>: Aug 04 08:09PM +0200

>> which becomes a bit complicated)?
 
> This is interesting
 
> http://stackoverflow.com/questions/21946447/how-much-performance-difference-when-using-string-vs-char-array
 
Yes, like one of the replies notices - using sprintf to build filenames
will let you start opening the file 0.12 microseconds earlier.
 
Wanna bet if someone will notice the speedup?
 
 
Bo Persson
Christopher Pisz <nospam@notanaddress.com>: Aug 04 02:09PM -0500

> Ebenezer Enterprises - "America didn't create religious liberty;
> religious liberty created America." Bobby Jindal
 
> http://webEbenezer.net
 
Like all the flawed comparisons, notice they never reserve even though
the length is known beforehand.
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
woodbrian77@gmail.com: Aug 04 12:18PM -0700

On Tuesday, August 4, 2015 at 2:09:19 PM UTC-5, Christopher Pisz wrote:
 
> Like all the flawed comparisons, notice they never reserve even though
> the length is known beforehand.
 
He makes a comment about that on one of the answers:

"I even tried to pre-declare and allocate space in the string in my answer, but that actually just caused things to slow down."
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
woodbrian77@gmail.com: Aug 04 12:38PM -0700

On Tuesday, August 4, 2015 at 1:10:21 PM UTC-5, Bo Persson wrote:
 
> Yes, like one of the replies notices - using sprintf to build filenames
> will let you start opening the file 0.12 microseconds earlier.
 
> Wanna bet if someone will notice the speedup?
 
I think it matters in aggregate. Programmers generally work on
processes that run periodically/frequently. And maybe you change
a number of std::string objects to arrays of char in your application.
 
 
Brian
Ebenezer Enterprises - If G-d has you on a short leash, every
little bit helps.
 
http://webEbenezer.net
Christopher Pisz <nospam@notanaddress.com>: Aug 04 02:50PM -0500


> Brian
> Ebenezer Enterprises - In G-d we trust.
> http://webEbenezer.net
 
I had no such trouble:
 
 
// Shared Library
#include "PerformanceTimer.h"
 
// Standard Library
#include <cstdio>
#include <iostream>
#include <string>
#include <vector>
#include <cmath>
 
using namespace std;
#define TRIALS 10000000
 
 
int main()
{
 
vector<double> secondsElapsedPerRun;
 
//const char * baseLocation = "baseLocation";
const string baseLocation = "baseLocation";
 
// Let's declare them both before hand rather than just the C version
// Let's also use std::string::reserve just like we supply the
length of the c-array
char fname[255] = {};
//string fname;
//fname.reserve(255);
 
Shared::PerformanceTimer timer;
for (int i = 0; i < TRIALS; ++i)
{
timer.Start();
 
_snprintf_s(fname, 255, "%s_test_no.%d.txt",
baseLocation.c_str(), i);
//fname = baseLocation + "_test_no." + std::to_string(i) + ".txt";
 
secondsElapsedPerRun.push_back(timer.Stop());
}
 
// Calculate sum
double sum = 0.0;
 
for(vector<double>::iterator vecIter =
secondsElapsedPerRun.begin(); vecIter != secondsElapsedPerRun.end();
++vecIter)
{
sum+= *vecIter;
}
 
double average = sum / static_cast<double>(TRIALS);
cout << "Average: " << average << " seconds" << endl;
 
// Calculate variance
double variance = 0;
 
for(vector<double>::iterator vecIter =
secondsElapsedPerRun.begin(); vecIter != secondsElapsedPerRun.end();
++vecIter)
{
variance += (*vecIter - average) * (*vecIter - average);
}
 
variance /= static_cast<double>(TRIALS);
 
cout << "Variance: " << variance << " seconds" << endl;
cout << "Std. deviation: " << sqrt(variance) << " seconds" << endl;
 
// Windows specific
system("pause");
}
 
 
 
 
C++ string
Average: 1.21634e-006 seconds
Variance: 5.56171e-013 seconds
Std. deviation: 7.45769e-007 seconds
 
C string
Average: 6.3834e-007 seconds
Variance: 4.31959e-012 seconds
Std. deviation: 2.07836e-006 seconds
 
Seems a bit more fair.
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
Doug Mika <dougmmika@gmail.com>: Aug 04 12:19PM -0700

On Saturday, August 1, 2015 at 1:43:32 PM UTC-5, Doug Mika wrote:
> condition_variable threadsReady;
> mutex dummyMtx;
> threadsReady.wait(unique_lock<std::mutex>(dummyMtx)); //this syntax seems to be wrong, but why?
 
that cleared it up...thanks to all
Me <me@right.her>: Aug 04 11:06AM -0400

I am using VC++ 2012 and serial transfer using Writefile & Readfile.
Serial params set to 115200baud, 8bits, no parity, 1 stop, no handshake.
Does anyone know why when I send data out to a virtual serial port there is
sometimes a delay up to 10 seconds before it actually goes out the port?
Sometimes it sends right away.
This is verified by activity led's on receiving board.
Receiving side is using FT230X USB/Serial chip.
Thanks in advance.
 
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Victor Bazarov <v.bazarov@comcast.invalid>: Aug 04 11:44AM -0400

On 8/4/2015 11:06 AM, Me wrote:
> Serial params set to 115200baud, 8bits, no parity, 1 stop, no handshake.
> Does anyone know why when I send data out to a virtual serial port there is
> sometimes a delay up to 10 seconds before it actually goes out the port?
 
Sorry to break it to you, but your question has nothing to do with C++
language (the subject of this newsgroup). Perhaps you can find a better
place to ask your OS- and hardware-specific question. So, to answer
your question, somebody in the newsgroup dedicated to serial
communication in Windows (if such exists) would likely know and be able
to help with your problem, or maybe in the general Windows programming
forum...
 
 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
 
V
--
I do not respond to top-posted replies, please don't ask
"Öö Tiib" <ootiib@hot.ee>: Aug 04 08:47AM -0700

On Tuesday, 4 August 2015 18:06:44 UTC+3, Me wrote:
> I am using VC++ 2012 and serial transfer using Writefile & Readfile.

There are no such things in C++. Did you write those yourself?
If so post your code. Did you mean 'WriteFile' and 'ReadFile' of Windows API?
There is whole MSDN for discussing that thing where you might get better
answers.
 
> Does anyone know why when I send data out to a virtual serial port there is
> sometimes a delay up to 10 seconds before it actually goes out the port?
> Sometimes it sends right away.
 
Perhaps you need to write 'Flushfilebuffers' function as well or to use
'FlushFileBuffers' of Windows API.
 
> This is verified by activity led's on receiving board.
> Receiving side is using FT230X USB/Serial chip.
> Thanks in advance.
 
Your receiving board has Windows that just blinks leds? Winner of most
uncomfortable development setup I have heard of.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)