Need for Speed - C++ versus Assembly Language

[hutch--]

There is an obvious elephant in the room here that everybody is desperately trying to avoid and that is processor family differences. Just as an example, the instruction LEA was genuinely fast on a PIII but turned into a lemon on a PIV. The next generation Core2 series hardware was a little kinder to LEA and the range of i7 hardware does not have a problem with it. SSE got a lot faster  with the Core2 and later series at the expense of simpler integer instructions getting slower as silicon was being pointed at later instructions.

Then for each family of processor you have a range of price driven variants that vary with their power design, cache size and frequency rate and collectively all of these many variants make the notion of a single piece of code being faster than another nonsense. The best you will get on similar age processors is a decent average across similar hardware and even that is dodgy.

The vast majority are messy in data and caching and much of the speed related advantages of one algo over another are wasted when the rest of the app is necessarily messy in how it works. It is not to say that its not worth the effort to manually optimise code but it is nowhere as simple as it is being made out here.

With this 6 core Haswell I work with at the moment, it is a nominally a 3.3gig processor but check the task manager and most of the time it sleeps in noddy mode at about 1.2 gig and only when it is loaded does it come up to speed. I have just recently tweaked my old i7 860 which was an overclockers toy some years ago by adding memory to it (8 up to 16 gig) then upped the clock from 2.8 to 3.5gig and it benchmarks faster than the Haswell.

[jj2007]

I never though about doing it in C/C++. I don't know whether it would be faster or not in this case

Well... can you really resist trying that one with MSVC?
 ;)

[aw27]

I never though about doing it in C/C++. I don't know whether it would be faster or not in this case

Well... can you really resist trying that one with MSVC?
 ;)

MSVC is faster for small matrixes. Tends to be slower and slower as the size grows.
But the ASM is not yet optimized.

[jj2007]

I have tried to build your code... first, Transpose.vcxproj launched VS Community, which took OVER THREE MINUTES to open. CRAP. Then it asked me to login to my M$ account (which I refuse to have) because the trial period is over. Redmond, this CRAPWARE was supposed to be FREE, right?

So I tried my commandline setup for MSVC: "c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sourceannotations.h(194): error C2059: syntax error: '['"

[RANT]
Great. And it seems that all my previously working sources show the same error. Thank you, VS Community, for introducing new "features".

Sorry, I give up on C/C++. Almost every time I put hand on C code, it ends up with endless searches on the web for somebody who solved the mystery of missing header files, or (in this case) header files that have "syntax errors" although I definitely never touched them. Not to mention the numerous attempts to load M$ "projects" which fail miserably because the current MSVC is not able to read the old obsolete crap that was saved in the previous version two years ago. Visual Crap just stinks. Kudos to Hutch - Masm32 works. Same to Pelle Orinius, btw - his C compiler works, too.

This afternoon I wasted over one hour trying to connect a phone to my PC with Bluetooth. Incredibly complicated, Windows help completely useless, it just sends you in circles, I gave up in the end. How could this "OS" survive so many years???

A helicopter was flying around above Seattle when an electrical malfunction disabled all of the aircraft's electronic navigation and communications equipment. Due to the clouds and haze, the pilot could not determine the helicopter's position and course to fly to the airport. The pilot saw a tall building, flew toward it, circled, drew a handwritten sign, and held it in the helicopter's window. The pilot's sign said "WHERE AM I?" in large letters. People in the tall building quickly responded to the aircraft, drew a large sign, and held it in a building window. Their sign read "YOU ARE IN A HELICOPTER." The pilot smiled, waved, looked at his map, determined the course to steer to SEATAC airport, and landed safely. After they were on the ground, the co-pilot asked the pilot how the "YOU ARE IN A HELICOPTER" sign helped determine their position. The pilot responded "I knew that had to be the Microsoft building because they gave me a technically correct, but completely useless answer."

[/RANT]

[TWell]

MS C compiler is good, standard headers are just c...
For that reason i use WDDK headers or just without those.
C is so flexible :t

EDIT: reminder

Code: [Select]

cl.exe -GS- -Zl -fp:fast -arch:SSE2 -d2noftol3 -O2 N4S.c DeterminantC.c -link -nocoffgrpinfo

[jj2007]

MS C compiler is good, standard headers are just c...

I didn't ask MS C to include sourceannotations.h :(

[aw27]

I have tried to build your code... first, Transpose.vcxproj launched VS Community, which took OVER THREE MINUTES to open. CRAP. Then it asked me to login to my M$ account (which I refuse to have) because the trial period is over. Redmond, this CRAPWARE was supposed to be FREE, right?

So I tried my commandline setup for MSVC: "c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sourceannotations.h(194): error C2059: syntax error: '['"

Don't forget that you can always delete it and have some peace of mind in the future.

[hutch--]

I confess I am no fan of the musical chairs that Microsoft play with their C/C+ versions. I have the source code from the SAPI 5 SDK for the app that runs the speech engine and I also have a perfect copy of the VC2003 environment that built everything from the old SDK onwards but when I tried to build the TTS app, it needed some AFX crap so I thought PHUKIT and tweaked the original executable in ResourceHacker, put a manifest into it so it looks like a modern app, redrew the dialog interface so that it was more or less useful and it is now worth using.

C was supposed to be portable, something that Microsoft have deliberately broken to keep the suckers dependent.

At least with Japheth's JWASM if you paddled through his makefile you could get the options and build it with a batch file but it WAS written to be portable. Built it in Pelle's C compiler as well.

[aw27]

At least with Japheth's JWASM if you paddled through his makefile you could get the options and build it with a batch file but it WAS written to be portable. Built it in Pelle's C compiler as well.

For JWASM, I did not even look at the makefile, in the editor I selected all .C and .H files and it compiled fine with VS 2015 both for 32 and 64-bit.

[hutch--]

Japheth used to recommend the VC2003 toolkit as it had better libraries than the later versions. I got it to build in VC10, VC2003 and Pelle's C but never with an IDE from Microsoft, always built with batch files. The VC2003 versions were smaller and faster.

[aw27]

Japheth used to recommend the VC2003 toolkit as it had better libraries than the later versions. I got it to build in VC10, VC2003 and Pelle's C but never with an IDE from Microsoft, always built with batch files. The VC2003 versions were smaller and faster.

Something older than VS 2005 has no interest for me now, support for 64-bit started there. In case of need I have DDKs as old as Windows Nt 4, or SDks not distributed anymore.

[hutch--]

It worries me much less with tools and utilities than it would with specific user apps, in most cases non-UI tools applications that are primarily single thread don't go any faster in 64 bit than 32 bit. Its where large memory is an advantage that 64 bit shines when you can routinely allocate multi-gigabyte blocks and multi-thread the processing of large amounts of memory.

[TWell]

test programs compiled with version 19.10 for x86 and x64
and x86 test programs compiled with versions 19.00  and 19.10

[aw27]

don't go any faster in 64 bit than 32 bit.

When the number of 64-bit CPU registers help reduce data in and out from memory it will a lot .

[hutch--]

Like x64 fastcall calling convention, many algorithms use less that 3 args on 32 bit and can be run as FASTCALL. You may be assuming that everything is done in 256 bit operations but many tasks are unaligned messes with mixed byte, word and dword data that defy later larger and faster registers. Then you have the code size difference, smaller 32 bit code uses less cache that equivalent 64 bit code and smaller data sizes load faster than big ones. Simple case is some code is faster in 32 bit, some other code is faster in 64 bit, anyone who is familiar with writing 32 bit assembler code already know how to be efficient with usable registers, the differences between inner and outer loop code and instruction choice.