- "Need for Speed - C++ versus Assembly Language" - 7 Updates
- Scalable Parallel C++ Conjugate Gradient Linear System Solver Library version 1.64 for Windows and Linux on (x86) - 1 Update
- std::experimental::atomic_shared_ptr - 1 Update
- Universal Scalability Law progam - 1 Update
- Boost circular buffer - 3 Updates
| Lynn McGuire <lynnmcguire5@gmail.com>: May 08 12:33PM -0500 "Need for Speed - C++ versus Assembly Language" https://www.codeproject.com/Articles/1182676/Need-for-Speed-Cplusplus-versus-Assembly-Language Neat ! I believe that ANY C++ compiler and linker duo can beat my hand written assembly language. Its been decades since I wrote any assembly language. Lynn |
| Vir Campestris <vir.campestris@invalid.invalid>: May 08 09:34PM +0100 On 08/05/2017 18:33, Lynn McGuire wrote: > Neat ! I believe that ANY C++ compiler and linker duo can beat my hand > written assembly language. Its been decades since I wrote any assembly > language. More to the point - I can write a big programme in C++ and make it work. Then profile it, and see how I can tune it. Which is more likely to be by algorithm than tweaking instructions. I haven't written assembler beyond initial system start for _years_. Though about 15 years ago I was astonished to find myself writing machine code... Andy |
| legalize+jeeves@mail.xmission.com (Richard): May 08 09:31PM [Please do not mail me a copy of your followup] Vir Campestris <vir.campestris@invalid.invalid> spake the secret code >> written assembly language. Its been decades since I wrote any assembly >> language. >More to the point - I can write a big programme in C++ and make it work. I like that C++ allows me to apply efficient abstractions at low levels as well as high levels. Modeling memory-mapped read-only registers with zero overhead compared to assembly is no big deal for C++. It would be amazingly painful in Java or C#. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| jacobnavia <jacob@jacob.remcomp.fr>: May 09 12:25AM +0200 Le 08/05/2017 à 22:34, Vir Campestris a écrit : > Then profile it, and see how I can tune it. Which is more likely to be > by algorithm than tweaking instructions. Then, for a given algorithm, you discover that tweaking instructions you can improve speed by 50, 100% or maybe more. The compiler must generate a program correct for for ALL possible C++ programs. The assembler programmer is generating instructions in his/her mind for THIS program only. This scope reduction makes the human much more flexible than any compiler since he/she KNOWS what is he/she doing in the global context of algorithm implementation. I am an assembly language programmer and I distribute a compiler system based on the C language, The compiler generates assembly. So, I like (and I have done it very often) to outsmart ANY compiler in just a few lines of ASM. It is fun. Contrary to what you could believe, I am not saying everyone should program in ASM. Asm is not for everyone. The given example is not really a fast asm program. As any language, you can write fast or slow programs in asm. The examples use too much shufps, for instance. Can't that be arranged otherwise in the pipeline? Not any preloading of the data is done using the advanced instructions of the x86 to preload the data. Why? Look, asm is not for everyone. Just for the people that like it. :-) jacob |
| jacobnavia <jacob@jacob.remcomp.fr>: May 09 12:29AM +0200 Le 08/05/2017 à 23:31, Richard a écrit : > Modeling memory-mapped read-only registers with zero overhead compared > to assembly is no big deal for C++. It would be amazingly painful in > Java or C#. Maybe you can explain what you mean with "memory-mapped read-only registers" ????? In any case if those registers have zero overhead they can't exist in the run time. All operations in the circuit take a certain time (also know as "cycle"). Zero overhead is something that doesn't exist. |
| jacobnavia <jacob@jacob.remcomp.fr>: May 09 12:33AM +0200 Le 08/05/2017 à 19:33, Lynn McGuire a écrit : > Neat ! I believe that ANY C++ compiler and linker duo can beat my hand > written assembly language. Its been decades since I wrote any assembly > language. It is funny that you do not even understand the irony of that sentence. Your hand written asm language is bad since you haven't a clue: It has been decades since you wrote any assembly. Everything has changed since the last decade. So, you shouldn't write any asm and stick to your C++. As far as making a generalization from your own personal incompetence in asm to some general principle of programming languages... I have some doubts about its scope. :-) |
| jacobnavia <jacob@jacob.remcomp.fr>: May 09 12:41AM +0200 Le 08/05/2017 à 19:33, Lynn McGuire a écrit : > written assembly language. Its been decades since I wrote any assembly > language. > Lynn In that example, a slow asm program is compared to the compiler output. Yes, the compiler wins. You can write fast asm programs, but you can write also so slow ones, that those programs are slower than a compiler. I am an assembly language programmer and I distribute a compiler system based on the C language, The compiler generates assembly. So, I like (and I have done it very often) to outsmart ANY compiler in just a few lines of ASM. It is fun. Contrary to what you could believe, I am not saying everyone should program in ASM. Asm is not for everyone. The examples use too much shufps, for instance. Can't that be arranged otherwise in the pipeline? Yes, a pipeline. Most machines now are deeply pipelined and that is one of the essential points. Compilers pipeline now, so it is no wonder that a program that uses half of the register file only and is not pipelined is slower. Big deal. Not any preloading of the data is done using the advanced instructions of the x86 to preload the data. Why? Look, asm is not for everyone. Just for the people that like it. It has been decades since you programmed anything in asm. So, go on using your c++ compiler and do not speak about things you know nothing about. jacob |
| rami17 <rami17@rami17.net>: May 08 06:17PM -0400 Hello... Scalable Parallel C++ Conjugate Gradient Linear System Solver Library version 1.64 for Windows and Linux on (x86) Author: Amine Moulay Ramdane Description: This library contains a Scalable Parallel implementation of Conjugate Gradient Dense Linear System Solver library that is NUMA-aware and cache-aware, and it contains also a Scalable Parallel implementation of Conjugate Gradient Sparse Linear System Solver library that is cache-aware. You can download it from here: https://sites.google.com/site/aminer68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library Thank you, Amine Moulay Ramdane. |
| woodbrian77@gmail.com: May 08 11:15AM -0700 On Sunday, May 7, 2017 at 1:29:33 AM UTC-5, Marcel Mueller wrote: > object. Neither holding the storage behind it. > Rule of thumb: *never use raw pointers* expecially not in conjunction > with smart pointers. I use raw pointers in my library code (onwards directory) and am not aware of what would be better. https://github.com/Ebenezer-group/onwards Brian Ebenezer Enterprises http://webEbenezer.net |
| rami17 <rami17@rami17.net>: May 08 01:49PM -0400 Hello... I have implemented my Universal Scalability Law progam.. Where do you use it ? You use it for example to optimize more the cost/performance ratio on multicores and manycores. With -nlr option means that the problem will be solved with the mathematical nonlinear regression using the simplex method as a minimization, if you don't specify -nlr, the problem will be solved by default by the mathematical polynomial regression, and since it uses regression , you can use it for example to test your system on many more cores with just a few points, and after that using regression it searchs for the cost/performance ratio that is optimal for you. Please read more about my Universal Scalability Law for Delphi and FreePascal, it comes with a graphical and a command-line program. I have included a 32 bit and 64 bit windows executables called usl.exe and usl_graph.exe inside the zip, please read the readme file to know how to use it, it is a very powerful tool. You can read about it and download it from here: https://sites.google.com/site/aminer68/universal-scalability-law-for-delphi-and-freepascal Thank you, Amine Moulay Ramdane. |
| Juha Nieminen <nospam@thanks.invalid>: May 08 10:10AM > Is it OK to use the templated circular buffer included in Boost to store > std::shared_ptrs to dynamically allocated objects? The documentation is talking about storing raw pointers in the container. std::shared_ptr is always safe to use in these containers. |
| woodbrian77@gmail.com: May 08 09:00AM -0700 On Monday, May 8, 2017 at 5:10:49 AM UTC-5, Juha Nieminen wrote: > > std::shared_ptrs to dynamically allocated objects? > The documentation is talking about storing raw pointers in the container. > std::shared_ptr is always safe to use in these containers. It depends on the compiler and hardware though: https://akrzemi1.wordpress.com/2017/05/05/the-gcc-bug-affects-you/ Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| woodbrian77@gmail.com: May 08 09:23AM -0700 > > std::shared_ptr is always safe to use in these containers. > It depends on the compiler and hardware though: > https://akrzemi1.wordpress.com/2017/05/05/the-gcc-bug-affects-you/ I heard about that bug on http://cppcast.com . |
| 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