- peformance of wait notify concept of condition variable - 1 Update
- std::experimental::atomic_shared_ptr - 1 Update
- Creating mutex pointer in c++ - 1 Update
- "Need for Speed - C++ versus Assembly Language" - 17 Updates
- How to use the second constructor? - 2 Updates
- Error message when defining a static data member - 1 Update
| "Chris M. Thomasson" <invalid@invalid.invalid>: May 11 04:03PM -0700 On 5/2/2017 6:28 AM, Scott Lurndal wrote: > to its knees rather quickly on a highly contended lock. Some > x86 processors will attempt to resolve starvation situations by > asserting a global bus lock which is very bad for system performance. Perfect! |
| "Chris M. Thomasson" <invalid@invalid.invalid>: May 11 02:23PM -0700 On 5/9/2017 8:09 AM, bitrex wrote: > I think the effect looks pretty nice for a software-generated effect, > though! Someday I'll learn more about OpenGL shaders and stuff... > http://imgur.com/a/TmFyc Marcel Mueller posts in this thread are great, feel no need to jump in. However, wrt shaders, check this crap out: http://webpages.charter.net/appcore/fractal/webglx/ct_complex_field.html (has point and click zoom, unfortunately has no unzoom...) Shaders are wonderful tools to work with. |
| "Chris M. Thomasson" <invalid@invalid.invalid>: May 11 02:18PM -0700 On 5/5/2017 12:30 AM, kushal bhattacharya wrote: >> deduction feature. This is only a convenience-feature. The resulting >> code is exactly the same. > thanks for this approach maam :) Bonita is okay. She just should try to give a proper attribution for once! Damn it, even a cut-and-paste of a name would be a first step. |
| Gareth Owen <gwowen@gmail.com>: May 11 07:27AM +0100 > (like __builtin_prefetch in gcc), and failing that, most compilers > will let you make small inline function that wraps a piece of inline > assembly. The interesting thing here is that Jacob claims that his hand-rolled assembler is almost always faster than translated code - and the original article makes the opposite claim - that peephole optimisations and knowledge of CPU scheduling issues make the compiler-generated ASM so baroque that its no human likely to generate it. But all the code being benchmarked is *right there*. There's a way for Jacob to prove that the failings of the hand-written ASM in the article is due to the skill of the programmer, not the irreducible complexity of the CPU scheduling. So come on Jacob - prove your point. Show us your ASM code, and how it outperforms both the original author's ASM and the C++ generated code. There's literally only one way to prove that humans can write faster ASM code than compilers on modern processors, and until then, its just claims. Gareth (who can run fast than Usain Bolt, but doesn't care to prove it) |
| David Brown <david.brown@hesbynett.no>: May 11 09:28AM +0200 On 11/05/17 08:27, Gareth Owen wrote: >> assembly. > The interesting thing here is that Jacob claims that his hand-rolled > assembler is almost always faster than translated code - and the I don't believe he has claimed it is /always/ the case - merely that it is sometimes the case. He gave some possible situations, many of which can be handled by today's compilers. > original article makes the opposite claim - that peephole optimisations > and knowledge of CPU scheduling issues make the compiler-generated ASM > so baroque that its no human likely to generate it. It is difficult to judge the quality of code like this. Algorithmic choices can make a huge difference, and it is hard to separate differences in algorithm detail from differences in implementation detail. It is all too easy to say the assembly code was badly written, or the C++ code was inefficient (what numpty thought that storing the matrices on the heap was a good plan?). > irreducible complexity of the CPU scheduling. > So come on Jacob - prove your point. Show us your ASM code, and how it > outperforms both the original author's ASM and the C++ generated code. That would be a very time-consuming task, with little to gain. > There's literally only one way to prove that humans can write faster ASM > code than compilers on modern processors, and until then, its just > claims. I think it would be far more informative to consider a case where Jacob thinks the C vs. assembly speed difference is relevant enough to make it worth the effort writing in assembly - a case where he already /has/ written the code in assembly. So let us consider 128 bit integer arithmetic. We define a large calculation, written in C, that uses 128 bit integers extensively. Jacob compiles it to run as an executable with his compiler that uses his assembly library for the calculations. The executable should be targeted to run on a modern 64-bit x86 processor, preferably both Windows and Linux versions. One or more other people write the same calculations, using a 128 bit integer type that is written in C or C++. We want at least three variants - one that is pure, standard C (or C++) with only common implementation assumptions stemming from the hardware. One that is free to use any extensions available on that compiler /except/ built-in 128-bit types. And one that uses the compiler's built-in 128-bit types. Then we compare speeds on several different computers. |
| jacobnavia <jacob@jacob.remcomp.fr>: May 11 10:35AM +0200 Le 11/05/2017 à 08:27, Gareth Owen a écrit : > There's literally only one way to prove that humans can write faster ASM > code than compilers on modern processors, and until then, its just > claims Exactly. Never program in asm, just stick to C++. Nothing is better than gcc, and will never be. Amen |
| Bonita Montero <Bonita.Montero@gmail.com>: May 11 01:08PM +0200 >> just claims > Exactly. Never program in asm, just stick to C++. Nothing is better > than gcc, and will never be. You impute him to make so stereotype statements which are specific for your statements about assembly. |
| scott@slp53.sl.home (Scott Lurndal): May 11 12:35PM >> code than compilers on modern processors, and until then, its just >> claims >Exactly. Never program in asm, just stick to C++. This is a reasonable dictum for the vast majority of C++ programmers. > Nothing is better than gcc, and will never be. I've never heard this sentiment expressed as such. I think you must be building a strawman to burn down. |
| Jerry Stuckle <jstucklex@attglobal.net>: May 11 09:59AM -0400 On 5/11/2017 2:27 AM, Gareth Owen wrote: > original article makes the opposite claim - that peephole optimisations > and knowledge of CPU scheduling issues make the compiler-generated ASM > so baroque that its no human likely to generate it. Compilers are written by humans, and so is the code generated by the compilers. A good assembler programmer knows the language. An expert assembler programmer knows the language *and the processor*. He/she can write the same code the compiler generates, so his/her code is never slower. However, the compiler still has constraints on it based on its design. The programmer has no such constraints. Additionally, the compiler generates code for a specific series of processors - i.e. 32 or 64 bit. If the programmer knows the code will only run on one specific processor, he/she can write code specific to that processor. With that said, there are very few assembler programmers with the required level of expertise nowadays. But they are out there. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| David Brown <david.brown@hesbynett.no>: May 11 05:09PM +0200 On 11/05/17 15:59, Jerry Stuckle wrote: >> so baroque that its no human likely to generate it. > Compilers are written by humans, and so is the code generated by the > compilers. Well, sort of. Compilers are written by humans, yes (though there can be layers of indirection, such as yacc). Humans write the code and macros that generate the object code sequences - they don't write the actual assembly code. When writing the output macro for translating "x * y", for example, the human-written code will say something like "Make sure x is in a register - call it rA. Make sure y is in a register - call it rB. Find a free register rD. Generate a "mul rD, rA, rB" instruction. The result is in rD, and the flag register is updated". the compiler will interlace this with other instructions, depending on processor scheduling and pipelining. It may lead to instructions to load a register from memory, it may not. Some types of code lead to complex object code generation - a switch might lead to a series of comparisons, a binary tree of comparisons, a jump table, calculated jumps, or a mixture. The compiler code generation is not just a copy-and-paste of sequences of hand-written assembly with a few register renames. There was a time, long ago, when that was the case (and it may still be the case in simpler compilers), but not now. The information about what instructions to use are, of course, given by a human - as is information about timing, pipelines, scheduling, etc., that helps the compiler pick between alternative solutions and interlacing. > A good assembler programmer knows the language. An expert assembler > programmer knows the language *and the processor*. Agreed. > He/she can write the > same code the compiler generates, so his/her code is never slower. In theory, yes. In practice - no, except for very short sequences or particular special cases. > However, the compiler still has constraints on it based on its design. > The programmer has no such constraints. In theory, yes - in practice, no. The programmer has constraints - there are limits to how well he/she can track large numbers of registers, or processor pipelines, or multi-issue scheduling. Making a small change in one part of the assembly can have knock-on effects in the timings in other parts. A human programmer simply cannot keep track of it all without an inordinate amount of time and effort. So /sometimes/ an assembler programmer can do better, especially on short sequences or particular cases that might map well to processor instructions but poorly to C code. But often it is simply too much effort - even an expert assembly programmer will not be willing to spend the time on the tedious detail, and has a high chance of getting at least something wrong. In particular, if you insist on writing clear and maintainable code in an appropriate timeframe, as most professional programmers aim for, then it is very rare that even an expert assembler programmer will beat a good compiler. It is perfectly possible to write clear and maintainable assembly code - but it is rarely the fastest possible result on a modern chip. > processors - i.e. 32 or 64 bit. If the programmer knows the code will > only run on one specific processor, he/she can write code specific to > that processor. Many compilers can generate code specifically for particular target processors. (Sorry, Jacob, but I must use gcc as the example again - it is the compiler I know best.) gcc has options to generate code that will work on a range of cpus (within a family such as x86-32) but have scheduling optimised for one particular target or subfamily. Or it can generate code that /requires/ a particular subfamily feature. Or it can generate a number of implementations for a given function, and pick the best one at run-time based on the actual cpu that is being used. Yes, all of that /can/ be done by an assembler programmer - but it is unrealistic to think that it /would/ be done, except in extreme cases. > With that said, there are very few assembler programmers with the > required level of expertise nowadays. But they are out there. Agreed. And they are mostly spending their time doing something /useful/ with those skills, rather than trying to beat compiler output by a fraction of a percent on one particular processor. For example, they are involved in writing compilers :-) |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 11 07:09PM +0100 On 09/05/2017 20:40, Robert Wessel wrote: > enough that people wouldn't guess that. And my understanding is that > a similar construct in French does not carry the same negative > connotation. Utter nonsense; I often refer to idiotic blokes (men) with the epithet "dear" to express my condescension of their fucktardedness. *You* are being sexist by claiming that "dear" just refers to women. And English *is* my first language (grade 'A', English O-level). /Flibble |
| Gareth Owen <gwowen@gmail.com>: May 11 07:16PM +0100 >> Nothing is better than gcc, and will never be. > I've never heard this sentiment expressed as such. I think you must > be building a strawman to burn down. Yup. But given that the last time I dared suggest he may not be right he accused me of bullying him, I'll gladly settle for this pathetic strawman argument that everyone immediately spotted as such. |
| jacobnavia <jacob@jacob.remcomp.fr>: May 11 08:30PM +0200 Le 11/05/2017 à 20:16, Gareth Owen a écrit : > Yup. But given that the last time I dared suggest he may not be right > he accused me of bullying him, I'll gladly settle for this pathetic > strawman argument that everyone immediately spotted as such. Correction. You wrote this: Le 09/05/2017 à 22:03, Gareth Owen a écrit : >> When faced with a neanderthal, best to face it and not pretend that it >> is normal. > Amen. You said Amen. You weren't just saying that I may not be right, you just tried to start a polemic for the nth time. Now you propose that I spend a month full time developing an asm program to prove that I can do better than gcc. Well, I have no interest in doing that. Just do not believe me and let's close this. I have no interest in proving you or anyone else about asm. Nobody is forcing to do that, and you can live the rest of your life never doing any asm as far as I am concerned. |
| Gareth Owen <gwowen@gmail.com>: May 11 07:36PM +0100 > Compilers are written by humans, and so is the code generated by the > compilers. My roomba was designed by humans, but that doesn't mean a human hoovered the sitting room. > A good assembler programmer knows the language. An expert assembler > programmer knows the language *and the processor*. He/she can write the > same code the compiler generates, so his/her code is never slower. In theory, yes of course. In practice, compilers and programmers - yes, even expert programmers - tend to produce code that looks very different. It's like saying that a human with a pen, paper and pocket calculator can solve a large travelling salesman optimisation problem using the same algorithm as a computer. Absolutely true, in theory. But computers are really good at algorithmically solving combinatorical optimisation problems quickly, and people aren't. Even the experts. Sure, they can solve them, but they can't do it quickly enough to be practical. > However, the compiler still has constraints on it based on its design. > The programmer has no such constraints. The programmer does have constraints: time & patience. |
| jacobnavia <jacob@jacob.remcomp.fr>: May 11 08:41PM +0200 Le 11/05/2017 à 20:09, Mr Flibble a écrit : > being sexist by claiming that "dear" just refers to women. > And English *is* my first language (grade 'A', English O-level). > /Flibble Well, that is the meaning I had in mind. I stated afterwards that I never meant anything that has to do with gender but yes, it was slightly condescending. I thought she missed something obvious: when you program in asm intrinsics with the compiler, you are doing asm and not c++. That discussion has nothing to do with women or men or gender discussions. Anyone can miss the obvious. That has nothing to do with being male or female... |
| Gareth Owen <gwowen@gmail.com>: May 11 07:44PM +0100 >>> is normal. >> Amen. > You said Amen. I did. > You weren't just saying that I may not be right, you just tried to > start a polemic for the nth time. "Trying to start a polemic"? "Bullying"? Anyway that wasn't what you described as "Bullying". You used that to describe some previous (unstated) interaction between us. On that I have literally no idea what you're talking about. On this - you were being sexist & condescending, and you got called on it. "Amen" here just means "I support Chris that sexism should be called out" > Now you propose that I spend a month full time developing an asm > program to prove that I can do better than gcc. It was MSVC++ actually. But never let the facts get in the way of a good polemic. > Just do not believe me and let's close this. OK. I shall. |
| Gareth Owen <gwowen@gmail.com>: May 11 07:45PM +0100 > Utter nonsense; I often refer to idiotic blokes (men) with the epithet > "dear" to express my condescension of their fucktardedness. *You* are > being sexist by claiming that "dear" just refers to women. You might. But Jacob doesn't, or at least he very rarely does on Usenet. Until now. When it happened to be addressed to a woman, which he assures was absolutely just a really, really big coincidence. Anyone want to buy a bridge? |
| jacobnavia <jacob@jacob.remcomp.fr>: May 11 09:05PM +0200 Le 11/05/2017 à 20:45, Gareth Owen a écrit : >> being sexist by claiming that "dear" just refers to women. > You might. > But Jacob doesn't, or at least he very rarely does on Usenet. I am rarely condescending, but sometimes when I think that somebody misses the obvious I can use this "dear" language construct. I could understand tghat you say that being condescending is bad, what I would agree to some extent. What is bothering is the following conclusion: > Until now. > When it happened to be addressed to a woman, which he assures was > absolutely just a really, really big coincidence. Since women represent 50% of the planet's population I have a 50% chance that when I am condescending, I am speaking with a woman. And here is the trolling: accusing people you do not know nor have any data whatsoever of having hidden prejudices, etc etc. > Anyone want to buy a bridge? No, just do it yourself. Stop trolling and discuss your views in a normal, unemotional tone. That's all it takes. |
| Gareth Owen <gwowen@gmail.com>: May 11 08:09PM +0100 > Discuss your views in a normal, unemotional tone. That's all it takes. Iatre, therapeuson seauton |
| Jerry Stuckle <jstucklex@attglobal.net>: May 11 03:45PM -0400 On 5/11/2017 11:09 AM, David Brown wrote: > types of code lead to complex object code generation - a switch might > lead to a series of comparisons, a binary tree of comparisons, a jump > table, calculated jumps, or a mixture. They cause the assembly code to be generated. It may be done indirectly as in your example (and good for compilers targeting different platforms), or it generate machine code directly. > of hand-written assembly with a few register renames. There was a time, > long ago, when that was the case (and it may still be the case in > simpler compilers), but not now. I never said it was a copy-and-paste. > The information about what instructions to use are, of course, given by > a human - as is information about timing, pipelines, scheduling, etc., > that helps the compiler pick between alternative solutions and interlacing. That is correct - and even the code that determines the results generated by those rules is created by humans. >> same code the compiler generates, so his/her code is never slower. > In theory, yes. In practice - no, except for very short sequences or > particular special cases. Maybe in your case. > small change in one part of the assembly can have knock-on effects in > the timings in other parts. A human programmer simply cannot keep track > of it all without an inordinate amount of time and effort. In practice, yes. There are limits to both registers and pipelines which a good programmer can handle. The same with scheduling. But I disagree that a small change in one part of the assembly will have any noticeable effect on unrelated code. > effort - even an expert assembly programmer will not be willing to spend > the time on the tedious detail, and has a high chance of getting at > least something wrong. In some cases, no amount of effort is "too much". I can think of many real-time systems where even saving a microsecond is important to the code. Data collection and analysis of large scientific projects such as the VLA (large array of radio telescopes), the NSF's LIGO (gravitational wave detector) and CERT's Large Hadron Detector are just three examples. > good compiler. It is perfectly possible to write clear and maintainable > assembly code - but it is rarely the fastest possible result on a modern > chip. It is perfectly possible to write clean and maintainable assembly code - and make it the fastest possible result. It's done every day at each of the above projects. > best one at run-time based on the actual cpu that is being used. > Yes, all of that /can/ be done by an assembler programmer - but it is > unrealistic to think that it /would/ be done, except in extreme cases. As I said - there are many instances in the scientific world where that is necessary. And there are programmers who do it. > /useful/ with those skills, rather than trying to beat compiler output > by a fraction of a percent on one particular processor. For example, > they are involved in writing compilers :-) Yes, they are doing something useful with their skills - and being paid quite handsomely for it. I only wish I had the level of expertise they do. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| fl <rxjwg98@gmail.com>: May 11 11:22AM -0700 Hi, I have a few code to use the below template. I figure out the 3rd constructor usage. How to use the 2nd constructor? Could you analyze it for me? Thanks, ---------------------------- sc_biguint<3> atomw(5); const sc_biguint<4> atomw1(2); atomw=atomw1; // 3 third constructor ........... template< int W > class sc_biguint : public sc_unsigned { public: // constructors sc_biguint() : sc_unsigned( W ) {} sc_biguint( const sc_biguint<W>& v ) // 2nd : sc_unsigned( W ) { *this = v; } sc_biguint( const sc_unsigned& v ) // 3 third : sc_unsigned( W ) { *this = v; } |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 11 09:13PM +0200 On 11-May-17 8:22 PM, fl wrote: > I have a few code to use the below template. I figure out the 3rd constructor > usage. How to use the 2nd constructor? Could you analyze it for me? The second constructor is an ordinary copy constructor. > sc_biguint<3> atomw(5); > const sc_biguint<4> atomw1(2); > atomw=atomw1; // 3 third constructor That's an assignment. Copy construction is more like sc_biguint a_copy = atomw1; or sc_biguint a_copy{ atomw1 }; > sc_biguint( const sc_unsigned& v ) // 3 third > : sc_unsigned( W ) > { *this = v; } Cheers & hth., - Alf |
| David Brown <david.brown@hesbynett.no>: May 11 08:46AM +0200 >>> I use a similar form as Stefan and am happy with it. >> You are atypical. > Not really. Others love G-d and country and baseball. This is a C++ newsgroup, and the discussion was on the C++ style of using a leading "::". In that, you are atypical. Nobody cares about your hobbies or whether they are popular or not. I don't believe I have seen the preceding :: style anywhere except from you and Stefan. Maybe there are a few more people that use it, but you will be heavily outweighed by people using "using" to minimise the need for ::, rather than people who add it superfluously. It is definitely atypical. |
| 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