- rational numbers - 4 Updates
- Some help needed - 7 Updates
- Tricky ... - 5 Updates
- "C++20 Coroutines" by Martin Bond - 9 Updates
| Paavo Helde <myfirstname@osa.pri.ee>: Sep 25 04:15PM +0300 24.09.2021 12:45 Ian Collins kirjutas: >> of the object you are trying to print). > The whole to_string() concept also falls apart if you are printing in a > template. int.to_string() anyone? Adding a stream adaptor for a class having only a to_string() is trivial: std::ostream& operator<<(std::ostream& os, const A& a) { os << a.to_string(); return os; } |
| Bart <bc@freeuk.com>: Sep 25 03:46PM +0100 On 25/09/2021 13:37, Paavo Helde wrote: > 3 they now require parens: > Python2: print 1, 2, 3 > Python3: print(1, 2, 3) That was one giant PITA. A lot of downloadable Python at one time was Python2. So you had to convert all the uses of 'print'. The change was to turn 'print' from a statement into a function, because it was 'better'. > put these print() definitions in sme common header file, and you can use > python3 style print syntax for all built-in and other types which > support stream<<. This is good. It doesn't handle all the possibilities of properly built-in Print, although print/println variations are easy. But it will do for quick debug prints where layout doesn't matter. |
| HorseyWorsey@the_stables.com: Sep 25 03:19PM On Sat, 25 Sep 2021 15:46:27 +0100 >> Python3: print(1, 2, 3) >That was one giant PITA. A lot of downloadable Python at one time was >Python2. So you had to convert all the uses of 'print'. Removing python2 syntax from python3 wasn't one of Guido's smartest moves. No reason it couldn't have been left in and deprecated. |
| Branimir Maksimovic <branimir.maksimovic@gmail.com>: Sep 25 05:16PM > Python2. So you had to convert all the uses of 'print'. > The change was to turn 'print' from a statement into a function, because > it was 'better'. This is why I don't like student code and libraries to use. They don't care about API and code stability... -- 7-77-777 Evil Sinner! |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 25 04:41PM +0200 I've developed a monitor-object like that of Java for C++ with some improvements. The major improvement is that there's not only a spin -loop for locking and unlocking but also for waiting on an event. In this case you don't have to lock the mutex but supply a predicate on a wait_poll-function and the code repeatedly tries to lock the mutex polling and if it can lock the mutex it calls the predicate which returns (or moves) a pair of a bool and the result-type. Waiting to for a semaphore and or a event-object (Win32) in the kernel can easily take from 1.000 to 10.000 clock-cylces even when the call immediately returns because the semaphore or event has been set before. So there has to be a spin count with a reasonable relationship to this waiting-inteval, f.e. spinning one tenth of the minimum interval being spent in the kernel. With my monitor-object I've taken the spincount recalculation-algorithm from the glibc. And I'm also using the PAUSE-instruction. But I think that the glibc induces to heavy cacheline-flipping by re-loading the mutex-flags immediately after a single PAUSE-instruction. So I decided to loop PAUSE several times and to take less spinning iterations there- fore. To get a reasonable number of PAUSE-spinnings I need the time PAUSE takes on different processors. On my CPU PAUSE halts the pipe only for about for 0,78 nanoseconds, which is about 3,25 clock-cycles in average. I've written a short progam tha repeatedly PAUSEs and takes the aveage time. I want to encourage you to compile the code on your machine and give me the PAUSE-timing it outputs here. This is the code: #include <iostream> #include <chrono> #include <cstddef> #include <cstdint> #include <immintrin.h> using namespace std; using namespace chrono; int main( int argc, char **argv ) { static uint64_t const PAUSE_ROUNDS = 1'000'000'000; auto start = high_resolution_clock::now(); for( uint64_t i = PAUSE_ROUNDS; i; --i ) _mm_pause(); double ns = (int64_t)duration_cast<nanoseconds>( high_resolution_clock::now() - start ).count() / (double)PAUSE_ROUNDS; cout << ns << endl; } |
| Paavo Helde <myfirstname@osa.pri.ee>: Sep 25 07:51PM +0300 25.09.2021 17:41 Bonita Montero kirjutas: > high_resolution_clock::now() - start ).count() / (double)PAUSE_ROUNDS; > cout << ns << endl; > } On my computer this outputs: 34.9194 (Intel Xeon E-2286M CPU @ 2.40 GHz) |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 25 07:01PM +0200 Am 25.09.2021 um 18:51 schrieb Paavo Helde: >> } > On my computer this outputs: > 34.9194 That seems much more reasonable to me than the < 4 clock cycles on my PC (Ryzen Threadripper 3990X). |
| Bo Persson <bo@bo-persson.se>: Sep 25 07:05PM +0200 On 2021-09-25 at 16:41, Bonita Montero wrote: > high_resolution_clock::now() - start ).count() / (double)PAUSE_ROUNDS; > cout << ns << endl; > } I get 30.7635 (Core i9 9900K 5GHz) |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 25 07:14PM +0200 Am 25.09.2021 um 19:05 schrieb Bo Persson: > I get > 30.7635 > (Core i9 9900K 5GHz) Why did AMD decide for such an idiotic timing ? That is neither suitable for spin-loops with only a single PAUSE-instructions, nor does it save power while spinning. |
| Branimir Maksimovic <branimir.maksimovic@gmail.com>: Sep 25 05:15PM > improvements. The major improvement is that there's not only a spin > for( uint64_t i = PAUSE_ROUNDS; i; --i ) > _mm_pause(); What's in _mm_pause ? -- 7-77-777 Evil Sinner! |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 25 07:16PM +0200 Am 25.09.2021 um 19:15 schrieb Branimir Maksimovic: >> for( uint64_t i = PAUSE_ROUNDS; i; --i ) >> _mm_pause(); > What's in _mm_pause ? Read again what I wrote or google for _mm_pause. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 25 03:57PM +0200 Am 25.09.2021 um 14:28 schrieb Branimir Maksimovic: >>> mainly for backward compatibility. For more information, see Remarks." >> What I do is reliable. > This is because you SAY SO? Inspect my code and say why it is not instead of making arbitrary assumptions. |
| Branimir Maksimovic <branimir.maksimovic@gmail.com>: Sep 25 01:59PM >> This is because you SAY SO? > Inspect my code and say why it is not instead of making > arbitrary assumptions. Show your code, I missed it :( -- 7-77-777 Evil Sinner! |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 25 04:09PM +0200 Am 25.09.2021 um 15:59 schrieb Branimir Maksimovic: >> Inspect my code and say why it is not instead of making >> arbitrary assumptions. > Show your code, I missed it :( I showed my wait_poll-function. It's sth. completely new that improves most usualy monitor-handling, usually with producer-consumer patterns where the mutex-part of the monitor is held very short. |
| Branimir Maksimovic <branimir.maksimovic@gmail.com>: Sep 25 05:13PM > I showed my wait_poll-function. It's sth. completely new that improves > most usualy monitor-handling, usually with producer-consumer patterns > where the mutex-part of the monitor is held very short. And you use unreliable function for that? -- 7-77-777 Evil Sinner! |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 25 07:15PM +0200 Am 25.09.2021 um 19:13 schrieb Branimir Maksimovic: >> most usualy monitor-handling, usually with producer-consumer patterns >> where the mutex-part of the monitor is held very short. > And you use unreliable function for that? Show me where my code is unreliable. I think you're simply a poor troll. |
| Branimir Maksimovic <branimir.maksimovic@gmail.com>: Sep 25 12:38PM > And a diabolical implementation of process spawning. Well if done properly it's just preemptive shceduler that can schedule on single or multiple cores/cpus -- 7-77-777 Evil Sinner! |
| Branimir Maksimovic <branimir.maksimovic@gmail.com>: Sep 25 12:44PM > That's part of your promise and can be inspected with a C++20-capable > debugger. Which one? -- 7-77-777 Evil Sinner! |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Sep 25 03:14PM +0200 On 20 Sep 2021 23:30, Lynn McGuire wrote: > hooks and basic functionality for supporting coroutines, but we must > incorporate this into our own classes. I anticipate that there will be > full library support for generator style coroutines in C++23." The main confusion about C++20 "coroutines" is that they're general coroutines. They're not: they're simple continuations, the special case of /stackless/ coroutines (no dedicated stack for each coroutine). While that's nice performance-wise it's very limited, and the Microsoft style support framework adopted in C++20 requires you to build a full fledged star ship in order to lift a little pebble; it's, well, moronic. --- I once started coding up real coroutines in terms of standard C++ threads. That could be very useful, in contrast to the mostly useless C++17 continuations. However, I stopped fiddling with it when the complexity of the implementation overwhelmed me. No doubt because of a lack of experience in safe multi-tasking. It would be really nice if SOMEONE could do this: real general coroutines, by leveraging real C++ threads. --- That could open the world of safe multi-tasking to C++ programmers in general. Another such enabler: an implementation of Ada-like rendezvous. And, and, ... Occam-like channels, maybe. :) - Alf |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 25 03:58PM +0200 Am 25.09.2021 um 14:44 schrieb Branimir Maksimovic: >> That's part of your promise and can be inspected with a C++20-capable >> debugger. > Which one? VS 2020 beta. |
| Branimir Maksimovic <branimir.maksimovic@gmail.com>: Sep 25 01:59PM >>> debugger. >> Which one? > VS 2020 beta. i am still on 2-17, didn't like 2-19. Let's try 2020 when I have time... -- 7-77-777 Evil Sinner! |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 25 04:23PM +0200 Am 25.09.2021 um 15:59 schrieb Branimir Maksimovic: >>> Which one? >> VS 2020 beta. > i am still on 2-17, didn't like 2-19. Let's try 2020 when I have time... I think sooner or later all C++IDEs will have the capabilility to debug inspect the state inside the promise of a coroutine. |
| HorseyWorsey@the_stables.com: Sep 25 03:04PM On Sat, 25 Sep 2021 13:14:40 +0200 >> easily accessable and modifiable in a debugger. >That's part of your promise and can be inspected with a C++20-capable >debugger. Oh very useful. So not only do you need a cutting edge debugger which might not be available in all execution enviroments, you have to interrogate a compiler generated object too. So simple compared to state variables! |
| HorseyWorsey@the_stables.com: Sep 25 03:28PM On Sat, 25 Sep 2021 15:58:16 +0200 >>> debugger. >> Which one? >VS 2020 beta. Quelle surprise! |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 25 06:44PM +0200 > Oh very useful. So not only do you need a cutting edge debugger which might > not be available in all execution enviroments, you have to interrogate a > compiler generated object too. So simple compared to state variables! You can be assured that in the near future most C++-capable debuggers will support that. |
| 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