News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

ASM Speed

Started by oex, July 29, 2010, 02:22:29 PM

Previous topic - Next topic

oex

OK I'm not heavily into compiling technologies but what I have gleaned from the wealth of knowledge backed by this forum is that C compilers rearrange code (as an ASM coder would) for best speed etc.... My assumption however is this doesnt happen in any way when using Windows API (or external libs?) for example....

In this case I can see that ASM would be massively faster than c apps when written properly.... Am I correct and are there any other cases where C compilers would fail to deliver good results and not at an instruction level ie rcl
We are all of us insane, just to varying degrees and intelligently balanced through networking

http://www.hereford.tv

ecube

from what i've seen in the debugger/testing over the years "optimized" c/c++ compiling was and still is a joke, people that claim otherwise are dillusional. And those that claim it matches quality hand written ASM are beyond help. I mean think about it, here in this community for example, it takes what 10/15 MINUTES for someone to write a faster version of some common used C function? that's sad, and what's sadder is, c/c++ has existed for what, over 20 years? they've had all that time, money and energy invested to get it beyond magical by now,but they haven't, not even close. ASM hasn't got anywhere near that kinda love, yet it still rocks  :bg C++ data types are a joke too, love all the million different types they have for the-same-damn-thing. If you try and compile majority of C/C++ 3rd party projects the one thing you're almost guaranteed to get is ERROR. :tdown

In reality I doubt C/C++ compilers will ever be to the level of quality hand written ASM. Reason I say that is, it's too easy for the asm dev to write hybrid functions for a paticular task, one that includes sse for example and caters to different scenarios/hardware capabilities. Donkey said in a previous post that C/C++ compilers "don't forget their optimization tricks" and while I wish that were true,from what i've seen they either 1)do or 2)don't know that many.

Example of Visual Studios "optimization" http://www.masm32.com/board/index.php?topic=13986.0 haha

hutch--

At their best a very good compiler produces reasonably good code almost all of the time but that is not good enough when you have some grasp of what code matters and what code does not. Universal optimisation rules mean your code is optimised as well as MessageBoxA where any reasonable manual control does spot optimisation while making sure the rest works correctly.

As usual, spend your time where it matters and just make sure the rest works OK.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

Twister

When I use C/C++ I don't normally think of the speed, you know. Just usually how quick I can finish this project.

cork

99% of people do just fine schlepping around in a Honda Accord and if you want to get somewhere undeniably fast you hop in your Lamborghini.

frktons

Quote from: Radio Ga Ga on July 30, 2010, 02:15:13 AM
When I use C/C++ I don't normally think of the speed, you know. Just usually how quick I can finish this project.

Microsoft invented .NET platform to do fast-food like code.
C/C++ are still a little bit slow compared to .NET platform in that field.  :P
Mind is like a parachute. You know what to do in order to use it :-)

redskull

Quote from: frktons on July 30, 2010, 07:51:47 AM
C/C++ are still a little bit slow compared to .NET platform in that field.  :P

Too bad that the faster you churn out pre-built code, the longer you have to spend debugging it and fixing it on the back end.  I've always seen software development as a zero-sum kind of game; you either put in the time now doing it right, or put in the time later fixing all the ways you did it wrong.

-r
Strange women, lying in ponds, distributing swords, is no basis for a system of government

ecube

yeah the .net platform is nice, and it just-makes-sense. The more abstract layers you add the better in terms of security, plus their JIT engine is neat. I'd imagine one day everything will be abstract, people won't go outside anymore they'll just "live their lives" inside some virtual reality because it's safer than real life. But i'm wondering off topic now, also I wasn't saying people shouldn't use C/C++, you can use whatever you want, I was just focusing on the speed debate.

clive

Quote from: cork on July 30, 2010, 04:07:35 AM
99% of people do just fine schlepping around in a Honda Accord and if you want to get somewhere undeniably fast you hop in your Lamborghini.

Or not, as the case may be....

http://www.dailymail.co.uk/news/article-1298651/1-2m-car-clamped-outside-Harrods-New-owners-hit-fine.html


This is so wrong on many levels, but then again my old boss used to get stopped for not putting front plates on his Ferrari's and Lamborghini's, and at least once doing >125 MPH in the F40
It could be a random act of randomness. Those happen a lot as well.

clive

Quote from: oex on July 29, 2010, 02:22:29 PM
OK I'm not heavily into compiling technologies but what I have gleaned from the wealth of knowledge backed by this forum is that C compilers rearrange code (as an ASM coder would) for best speed etc.... My assumption however is this doesnt happen in any way when using Windows API (or external libs?) for example....

In this case I can see that ASM would be massively faster than c apps when written properly.... Am I correct and are there any other cases where C compilers would fail to deliver good results and not at an instruction level ie rcl

You know this depends very much on the processor target.

With architectures with high register counts (say MIPS, ITANIUM), it can get hard to keep track manually of what is kept where, or implement optimum register management. I'm not saying humans can't do it, just that it can get very labourious especially if you add/change things around a lot. Some of these tasks are better automated, either by a compiler, or a post assembly stages.

Again with ITANIUM or CRUSOE, you have a VLIW, and keeping track of what instructions you can group together and which will result in hardware hazards, is something screaming to be automated. Even if you want to code in assembler, it's always useful to have tools that will analyze and tune what you are writing. MASM used to be able to provide instruction cycle estimates, and I've built things to add timing estimates to 68000 listings.

Many compilers do a very good job these days, certainly the ones that analyze the code more completely. Some do look at the application as a whole, but it's hard to optimize across a subroutine or API that is a black-box, and is generally assumed to change/alter the system state. Compilers don't understand your algorithms, so they are always going to be at a disadvantage. They can, along with the linker, do a good job of identifying and eliminating dead code.

Compilers permit you to be very productive, very quickly, assembler lets you optimize performance where it is critical.
It could be a random act of randomness. Those happen a lot as well.

GregL

Quote from: frktonsC/C++ are still a little bit slow compared to .NET platform in that field.  Tongue

What?  Native C code is much faster than the equivalent managed C# (.NET) code.

Rockoon

Quote from: Greg Lyon on July 30, 2010, 08:27:22 PM
Quote from: frktonsC/C++ are still a little bit slow compared to .NET platform in that field.  Tongue

What?  Native C code is much faster than the equivalent managed C# (.NET) code.


Thats not always true. It depends on the compiler.

The compilers from Visual Studio 98 (which of course includes Visual C++) do not produce as good of code, on average, as the current .NET JIT.

The latest compilers do some amazing optimizations.. stuff that is very difficult (time-consuming!) in asm they do instantly, such as the latest trend in whole-program optimization where constants are folded even across modules/libraries.. calling a library procedure which calls other library procedures might produce no code at all these days if the initial call contained only constants.

Compilers are still poor on the micro-optimization front, and algorithmic-optimizations are language agnostic and always done by programmers, but dont discount the latest compilers (including the .NET JIT) at the things they are good at. They really are very good at some things.



When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using one.

frktons

Quote from: Greg Lyon on July 30, 2010, 08:27:22 PM
Quote from: frktonsC/C++ are still a little bit slow compared to .NET platform in that field.  Tongue

What?  Native C code is much faster than the equivalent managed C# (.NET) code.

I was talking about the speed of creating an application, not the speed of the code running.  :P
Mind is like a parachute. You know what to do in order to use it :-)

GregL

QuoteI was talking about the speed of creating an application, not the speed of the code running.  Tongue

Oh, I would agree with you on that, especially a GUI application.

Rockoon

The whole Rapid-GUI thing isn't really built into languages. Its built into the development environments which are language-specific.

There is no reason that assembler IDE's cant have these sorts of code-generating frameworks other than that nobody has invested as much time as the big players have for their HLL's .. and on that note, ASM environments like EasyCode actually does a lot of the GUI heavy lifting for you if you want to make full blown ASM programs with GUI's
When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using one.