- Serial communications problem - 5 Updates
- What practice can get speed improvement in C++? - 5 Updates
- Understanding the new memory model - 1 Update
| seeplus <gizmomaker@bigpond.com>: Aug 04 10:59PM -0700 On Wednesday, August 5, 2015 at 1:06:44 AM UTC+10, Me wrote: > 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? What platform is this, is it GUI? Are you sending to an Arduino type thing? Might get some help from that area. If Windows, is the OS loaded down doing other stuff at times? I have found when running non Win type threads, that you have to fit in with the Win message/slicing scheme to get attention. You need to use an API/MFC setup for GUI operations. |
| Me <me@right.her>: Aug 05 01:11PM -0400 On Tue, 4 Aug 2015 11:06:12 -0400, Me wrote: > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus Just to give a little more info: I am using Visual Studio C++ 2012 with a MFC aplication. I tried asking in a group for MFC but the group seems dead and cannot find another so I thought I'd give it a shot here. The receiving board uses a LPC1768 MCU and has a usb to serial chip which has activity indicator outputs. this board receives data from the PC to control a custom scanner. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus |
| Paavo Helde <myfirstname@osa.pri.ee>: Aug 05 01:01PM -0500 Me <me@right.her> wrote in > Just to give a little more info: > I am using Visual Studio C++ 2012 with a MFC aplication. > I tried asking in a group for MFC but the group seems dead This is probably because MFC has been out of fashion for at least 15 years. Also beware that it contains some seriously ill-defined classes like CSocket, hopefully you are not using something like this. Cheers Paavo |
| Cholo Lennon <chololennon@hotmail.com>: Aug 05 03:27PM -0300 On 08/05/2015 02:11 PM, Me wrote: > I am using Visual Studio C++ 2012 with a MFC aplication. > I tried asking in a group for MFC but the group seems dead and cannot find > another Microsoft replaced its newsgroups with web forums in 2010. You should ask here: https://social.msdn.microsoft.com/Forums/en-US/home?forum=vcgeneral Regards -- Cholo Lennon Bs.As. ARG |
| red floyd <no.spam@its.invalid>: Aug 05 01:20PM -0700 On 8/5/2015 10:11 AM, Me wrote: > I tried asking in a group for MFC but the group seems dead and cannot find > another so I thought I'd give it a shot here. I wanted to buy some meat, but the butcher was closed, so I tried to buy some at the greengrocer's instead. |
| Juha Nieminen <nospam@thanks.invalid>: Aug 05 08:12AM > This is interesting > http://stackoverflow.com/questions/21946447/how-much-performance-difference-when-using-string-vs-char-array They are not doing the same thing. Formatted printing into a static buffer is not the same thing as building a dynamic string by appending stuff. If std::sprintf() is sufficient for the task at hand, then definitely use that. (After all, I did mention in my post that C I/O functions tend to be more efficient than the C++ equivalents.) Now, if you were doing the *same* thing in both cases, however, things may be different. (For one, appending to a C string ought to be slower than appending to a std::string, if for nothing else, then because in the former case knowing were to append is an O(n) operation. And of course dynamically growing the string as needed is a PitA using C strings.) --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| "Öö Tiib" <ootiib@hot.ee>: Aug 05 03:55AM -0700 On Tuesday, 4 August 2015 21:10:21 UTC+3, 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? Someone might notice something other but speedup however. The code in question ignores return value of 'snprintf'. It does not check if it is less than 255. It does not allocate bigger buffer if it isn't. So most important customer who has the application installed in a way that path to file exceeds the limits of 'fname' will notice that the junk we sold him does strange things and crashes. ;-) |
| "Öö Tiib" <ootiib@hot.ee>: Aug 05 04:11AM -0700 > > 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." It is because the 'string::string(string&&)' called in benchmark does move and if to replace it with 'string::operator=(string&&)' then it will move anyway (and so release the pointlessly 'reserve'd buffer). 'string::reserve' has point if you 'append' or '+=' to it. The whole benchmark is a joke, the outcome of it is passed nowhere and the work in 'for' cycle is pointless 'nop' in essence. No wonder since real software rarely needs sliced to 254 characters pieces of texts. |
| Martin Shobe <martin.shobe@yahoo.com>: Aug 05 08:53AM -0500 On 8/5/2015 3:12 AM, Juha Nieminen wrote: > If std::sprintf() is sufficient for the task at hand, then definitely > use that. (After all, I did mention in my post that C I/O functions > tend to be more efficient than the C++ equivalents.) Just for fun, I run the tests above using Visual Studio 2013 (I used the default release options and _snprintf instead of snprintf. I also added a test for stringstream performance.) and got the following results. Length is the length of the string in baseLocation. stream is the average time to build the filename using a stringstream. reserve is the average time using a string with a reserved buffer. string is using a string without using a reserved buffer. Array is the c-style array. length stream reserve string array 12 8.6122 3.7423 4.4735 4.6979 microseconds 78 7.8117 3.7714 4.4523 6.3554 microseconds Which I think provides evidence for the maxim about measuring. Martin Shobe |
| Bo Persson <bop@gmb.dk>: Aug 05 05:03PM +0200 > 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. And you don't think that actually opening the file will hide the difference (being fractions of a microsecond)? Bo Persson |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 05 01:24AM +0100 On Tue, 4 Aug 2015 21:38:12 +0100 > 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." Technically I don't think that applies to mutexes because although a mutex represents a memory location it does not of itself offer atomic stores and loads. Non-normatively, for mutexes the result you mention is offered by §1.10/5 of C++11: "Note: For example, a call that acquires a mutex will perform an acquire operation on the locations comprising the mutex. Correspondingly, a call that releases the same mutex will perform a release operation on those same locations. Informally, performing a release operation on A forces prior side effects on other memory locations to become visible to other threads that later perform a consume or an acquire operation on A." The normative (and more hard-to-read) requirement for mutexes is in §30.4.1.2/11 and §30.4.1.2/25 ("synchronizes with") read with §1.10/11 and §1.10/12 ("happens before") and §1.10/13 ("visible side effect"). So far as concerns acquire and release operations on atomic variables, these also provide synchronization, in that informally an operation with acquire semantics is one which does not permit subsequent memory operations to be advanced before it, and an operation with release semantics is one which does not permit preceding memory operations to be delayed past it, as regards the two threads synchronizing. This synchronization with respect to those two threads extends beyond just the memory location represent by the particular atomic variable. It applies generally to all operations on memory locations shared by the two threads performing the acquire/release on the particular atomic variable (but does not provide full sequential consistency with respect to atomic operations performed by other threads). A consume operation on the other hand only synchronizes on the particular atomic variable and its dependencies. In practice, no one bothers about consume operations except in the most obscure circumstances. Likewise the need for full sequential consistency with other threads for atomic variables is also relatively uncommon, nothwithstanding that it is the default for atomics. Chris |
| 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. |
No comments:
Post a Comment