- #define - 7 Updates
- About my ParallelFor() that scales very well - 1 Update
- casting that's a lot of extra typing :-) - 3 Updates
| "Öö Tiib" <ootiib@hot.ee>: Jul 05 09:10AM -0700 On Thursday, 4 July 2019 07:21:17 UTC+3, G G wrote: > #define _PROTOTYPE(function, params) function params > how does this work? Studying C++ by asking meaning of each individual keyword or preprocessor directive (perhaps found in some system library implementation file) will be quite long and difficult way. Better find some good textbook or tutorial about the language. About preprocessor look at that for example: http://www.cplusplus.com/doc/tutorial/preprocessor/ |
| G G <gdotone@gmail.com>: Jul 05 10:16AM -0700 On Friday, July 5, 2019 at 12:10:30 PM UTC-4, Öö Tiib wrote: > Better find some good textbook or tutorial about the language. > About preprocessor look at that for example: > http://www.cplusplus.com/doc/tutorial/preprocessor/ ok but there is a preprocessor section in both the books i'm reading and that looked odd and both books say that the directives are really not the c++ way templates are a better thought for c++, so they say. but they continue on to say one should learn about those directives because one may see them in c programs. this particular one just looks odd to me. #define _PROTOTYPE(function, params) function params when it sees _PROTOTYPE(function, params) it replaces it with the words function params, i can't imagine that compiling |
| Keith Thompson <kst-u@mib.org>: Jul 05 10:55AM -0700 > #define _PROTOTYPE(function, params) function params > when it sees _PROTOTYPE(function, params) it replaces it with the > words function params, i can't imagine that compiling Given the name, my guess is that this is one of two alternative definitions, used so that you can write code that will compile either with a compiler that supports prototype, or with one that won't. If so, it's useless for C++, which has (practically) *always* supported prototypes. I've seen such macro definitions in code that needs to be compiled with pre-ANSI (pre-1989) C compilers. If you're trying to learn how to use the preprocessor in C++, you're probably using a very poor example. And by not showing any context, you've made it difficult for us to say much about it without guessing. Where did you see this macro? -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| G G <gdotone@gmail.com>: Jul 05 03:40PM -0700 > Where did you see this macro? > -- > Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> http://www.minix3.org/documentation/AppendixB.pdf line 00034 |
| "Öö Tiib" <ootiib@hot.ee>: Jul 05 04:10PM -0700 On Saturday, 6 July 2019 01:40:40 UTC+3, G G wrote: > > Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> > http://www.minix3.org/documentation/AppendixB.pdf > line 00034 Can you notice that it is Minix 3 implemented in C programming language. C is (somewhat compatible but) different programming language than C++. C is great programming language but knowledge of it is not required (and can sometimes be detrimental) for studying C++. Learning C++ by studying C source code is therefore wrong. Even when the techniques that you learn happen to work in both languages (and the set of such techniques diminishes over time) these are often not considered optimal for C++ and so can be reasonably frowned upon by experienced C++ programmers. Also taking something as complex as (even most trivial) operating system is way over head task for most beginners. Minix 3 is Unix clone and so no way among most trivial of operating systems. |
| G G <gdotone@gmail.com>: Jul 05 04:19PM -0700 On Friday, July 5, 2019 at 7:10:24 PM UTC-4, Öö Tiib wrote: > > line 00034 > Can you notice that it is Minix 3 implemented in C programming > language. yes |
| G G <gdotone@gmail.com>: Jul 05 04:22PM -0700 On Friday, July 5, 2019 at 7:20:02 PM UTC-4, G G wrote: > > Can you notice that it is Minix 3 implemented in C programming > > language. > yes i stop at line 34. preprocessor macros are you say those preprocessor statement would not work in C++? |
| Horizon68 <horizon@horizon.com>: Jul 05 02:50PM -0700 Hello, About my ParallelFor() that scales very well that uses my efficient Threadpool that scales very well: With ParallelFor() you have to: 1- Ensure Sufficient Work Each iteration of a loop involves a certain amount of work, so you have to ensure a sufficient amount of the work, read below about "grainsize" that i have implemented. 2- In OpenMP we have that: Static and Dynamic Scheduling One basic characteristic of a loop schedule is whether it is static or dynamic: • In a static schedule, the choice of which thread performs a particular iteration is purely a function of the iteration number and number of threads. Each thread performs only the iterations assigned to it at the beginning of the loop. • In a dynamic schedule, the assignment of iterations to threads can vary at runtime from one execution to another. Not all iterations are assigned to threads at the start of the loop. Instead, each thread requests more iterations after it has completed the work already assigned to it. But with my ParallelFor() that scales very well, since it is using my efficient Threadpool that scales very well, so it is using Round-robin scheduling and it uses also work stealing, so i think that this is sufficient. Read the rest: My Threadpool engine with priorities that scales very well is really powerful because it scales very well on multicore and NUMA systems, also it comes with a ParallelFor() that scales very well on multicores and NUMA systems. You can download it from: https://sites.google.com/site/scalable68/an-efficient-threadpool-engine-with-priorities-that-scales-very-well Here is the explanation of my ParallelFor() that scales very well: I have also implemented a ParallelFor() that scales very well, here is the method: procedure ParallelFor(nMin, nMax:integer;aProc: TParallelProc;GrainSize:integer=1;Ptr:pointer=nil;pmode:TParallelMode=pmBlocking;Priority:TPriorities=NORMAL_PRIORITY); nMin and nMax parameters of the ParallelFor() are the minimum and maximum integer values of the variable of the ParallelFor() loop, aProc parameter of ParallelFor() is the procedure to call, and GrainSize integer parameter of ParallelFor() is the following: The grainsize sets a minimum threshold for parallelization. A rule of thumb is that grainsize iterations should take at least 100,000 clock cycles to execute. For example, if a single iteration takes 100 clocks, then the grainsize needs to be at least 1000 iterations. When in doubt, do the following experiment: 1- Set the grainsize parameter higher than necessary. The grainsize is specified in units of loop iterations. If you have no idea of how many clock cycles an iteration might take, start with grainsize=100,000. The rationale is that each iteration normally requires at least one clock per iteration. In most cases, step 3 will guide you to a much smaller value. 2- Run your algorithm. 3- Iteratively halve the grainsize parameter and see how much the algorithm slows down or speeds up as the value decreases. A drawback of setting a grainsize too high is that it can reduce parallelism. For example, if the grainsize is 1000 and the loop has 2000 iterations, the ParallelFor() method distributes the loop across only two processors, even if more are available. And you can pass a parameter in Ptr as pointer to ParallelFor(), and you can set pmode parameter of to pmBlocking so that ParallelFor() is blocking or to pmNonBlocking so that ParallelFor() is non-blocking, and the Priority parameter is the priority of ParallelFor(). Look inside the test.pas example to see how to use it. Thank you, Amine Moulay Ramdane. |
| Juha Nieminen <nospam@thanks.invalid>: Jul 05 06:20AM > That's an not fitting analogy. C++-style casts just don't have an > advantage on the maintainability, deveopment-performance and ease > of writing. Yes, they have. Especially when used aliased or custom types, a static_cast will make sure you don't accidentally cast into an incompatible type, which most often than not is a bug, which in this case would be caught as early as possible in the development process, ie. when compiling. They also make it visually easier to see where explicit casts are being done, because they don't look like normal function calls. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jul 05 09:52AM +0200 > Yes, they have. Especially when used aliased or custom types, > a static_cast will make sure you don't accidentally cast into an > incompatible type, ... I've never seen such bugs with C-style casting. This kind of child-proof lock in C++ is simply useles. |
| Manfred <noname@add.invalid>: Jul 05 06:47PM +0200 On 7/5/2019 9:52 AM, Bonita Montero wrote: >> a static_cast will make sure you don't accidentally cast into an >> incompatible type, ... > I've never seen such bugs with C-style casting. Then you don't have seen much of it. > This kind of child-proof lock in C++ is simply useles. Just the opposite, as many have said. |
| 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