How fast is it really?

Index > Main > How fast is it really?

Goto page Previous 1, 2, 3 Next

Author

Thread

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 24 Mar 2008, 02:59

The speed of assemblers differ greatly in respect to your processor, author's skill, as well as things like output format and how modularized (broken up into pieces) your project is. Oh, and it's already been proven that too many macros can slow everything down (even for FASM!).

FASM is fast assembly. It needs no C compiler, it can assemble itself. It outputs various formats. FASM is probably the best (although NASM/YASM are darn good too).

However, NASM can handle OBJ output (unlike FASM) among others like ELF, COFF, etc. You can always use the last CC386 (discontinued), which is a very small download, to compile NASM 0.98.39 at least (never tried latest yet, apparently now needs C99 compiler ... possibly only GCC 4.x). And OpenWatcom 1.7a is finally available as separate .ZIPs, so you could get the C compiler only (< 10 MB probably) and compile even the latest 2.02 fairly easily (included makefiles which work with some predefined hacks in srcs), if you really really needed to. Otherwise, it's moot. BTW, in my wimpy projects, I've noticed that YASM is quite a bit faster than NASM "-Ox" (at least when benchmarking on my old 486 Sx/25, lol), probably due to its re2c parser. The performance isn't as noticeable on newer computers, though.

Some others (old old old Arrowsoft ASM and new LZASM) only handle OBJ/OMF. So, if you want to create a bunch of executables, it would be slower having to invoke a linker a billion times than just directly create 'em via FASM "format mz" etc.

Octasm is super fast too (pure assembly, assembles itself) but is somewhat limited in output formats (pure binary and .SYM debug constants file). Others don't support all the latest instructions (e.g. MASMv6, TASM, Pass32, POASM lacks any 16-bit) or may produce bad code if used incorrectly (Watcom's WASM, GAS??).

So, in short, direct .EXE production is fastest (and NASM has such macros for .EXE, at least), but that's probably what you'll have to do with most assemblers if you want to avoid the linker step: hardcoded MZ / PE headers in flat binary. (And yes, I know most people won't do that, just mentioning it.)

Randy, I suggest you try benchmarking YASM vs. NASM and see what happens. You might even want to recompile NASM with "-march=native" or "-mtune=generic" to see if that helps (and even recompile YASM too). GCC 4.x is better than GCC 3.x or OpenWatcom at code generation. For that matter, good luck recompiling GAS too! Wink

24 Mar 2008, 02:59

rhyde

Joined: 03 May 2007
Posts: 21

rhyde 24 Mar 2008, 20:11

revolution wrote:

rhyde wrote:
NASM is a good choice as it's available on more OSes than even Gas.
The problem that I see with NASM is that it is not self contained, it requires a C compiler. The advantage I see with NASM is that it is not self contained, it uses a C compiler.

???
NASM is *written* in C. But that's hardly relevant to the OP's question. You don't need a C compiler to produce object files from NASM using NASM. NASM will (and does!) process output from some compiler and produce an object file that can be linked to produce an executable. That's all a compiler writer needs. The implementation language is of little interest as long as an executable version of NASM is lying around. And if one is not, the fact that NASM is written in C and can be compiled on nearly any OS with a C compiler is a *big* plus compared with assemblers, such as FASM, where the assembler is written in assembly language.

Bottom line still remains, however, that NASM is a bit too slow to use as a back-end assembler for a compiler. Gas is almost as portable and is much faster. So unless someone needed a back-end assembler under some OS that NASM supports but Gas does not, Gas is generally a better choice.

I should address a comment made elsewhere in this thread.
Someone mentioned that the speed of assemblers is not as important as the feature set. While this is certainly true for most people, for use as a back-end assembler to a compiler it is not much of an issue. The reason is that most compilers don't use a lot of fancy features in the back-end assembler. Displacement-optimization, forward references, and stuff like that is about the most exotic things you'll find a compiler using. Rarely will features like fancy macros, conditional compilation, type checking, and so on, make it into the source code output a compiler produces for a back-end assembler.
Cheers,
Randy Hyde

24 Mar 2008, 20:11

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 24 Mar 2008, 21:02

Randy, uh yes, I know NASM is written in C. And if you need to modify it for your needs (like Ladsoft did), you need to find a compiler that will build it (not necessarily an easy feat depending on your OS and C99 compatibility of your compiler). At least nowadays, current NASM won't build for anything < 386. So much for "ultimate portability" (although truly, very few people need 16-bit compiles).

Anyways, it's not so great an advantage being portable for a program that is (mostly) useless to other architectures anyways. Has anybody actually written a cross compiler that uses NASM yet?? And the only compiler I know that uses NASM for a backend is CC386. Various compilers use FASM (e.g. Context, PureBasic), so in reality the platform portability isn't much (if any) disability.

As far as GAS is concerned, of course it's faster than NASM ... its main goal is to be a backend. (And GNU has more support than NASM ever will.)

P.S. You didn't test YASM yet? Try a latest snapshot (Win32 or DOS .EXE or src), and tell me if you find it faster than NASM.

24 Mar 2008, 21:02

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 24 Mar 2008, 21:22

rugxulo: there is still 32bit / 64bit portability, which is quite useful

24 Mar 2008, 21:22

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 24 Mar 2008, 21:24

vid wrote:

rugxulo: there is still 32bit / 64bit portability, which is quite useful

Yeah, but name one instance that NASM is useful and FASM would not be? Cross compiling from Solaris SPARC? Cross compiling from Mac OS X (PPC)? (Even on those platforms you could use QEMU, BOCHS, DOSBox, etc. and run FASM that way, so I don't think NASM is too superior in that regard.)

24 Mar 2008, 21:24

gunblade

Joined: 19 Feb 2004
Posts: 209

gunblade 24 Mar 2008, 21:38

vid wrote:

rugxulo: there is still 32bit / 64bit portability, which is quite useful

Thats true, but fasm 32-bit will run on pretty much any 64-bit linux kernel anyway, since they provide the option to execute 32-bit code. The only problems you could come across when running 32-bit programs on a 64-bit kernel is that all the libraries which that program uses have to also be 32-bit. But since fasm does not use any libraries at all, it will run on pretty much any 64-bit linux. (I know theres other systems, just saying, its not an issue for linux Smile

)

24 Mar 2008, 21:38

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system

revolution 24 Mar 2008, 23:53

NASM does ARM or not? YASM does ARM or not?

24 Mar 2008, 23:53

f0dder

Joined: 19 Feb 2004
Posts: 3175
Location: Denmark

f0dder 25 Mar 2008, 00:14

rugxulo wrote:

Randy, uh yes, I know NASM is written in C. And if you need to modify it for your needs (like Ladsoft did), you need to find a compiler that will build it (not necessarily an easy feat depending on your OS and C99 compatibility of your compiler). At least nowadays, current NASM won't build for anything < 386. So much for "ultimate portability" (although truly, very few people need 16-bit compiles).

If you're targetting an OS where you can't find a compiler with C99 compatibility, or where you're limited to a 16-bit address space, aren't you better off cross-compiling for that OS from a more capable development platform, anyway?

25 Mar 2008, 00:14

CBB

Joined: 28 Feb 2008
Posts: 7

CBB 28 Mar 2008, 02:37

Code:

Last edited by CBB on 31 Mar 2008, 22:09; edited 1 time in total

28 Mar 2008, 02:37

Octavio

Joined: 21 Jun 2003
Posts: 366
Location: Spain

Octavio 28 Mar 2008, 11:23

CBB wrote:

- Take a typical 2000 - 3000 lines of code C source file with typical code (i.e. not just large struct tables or somesuch)
- Assume an x86/ELF system
- Translate it to a gas and a fasm version, WITHOUT using macros or high level constructs!

How fast would they assemble?

From my tests Fasm needs betwen 5000-10000 cpu clocks (P3) to assemble one instruction, don't know how fast is Gas but for a typical 2000 - 3000 lines of code C the assembly time is insignificant and the assemblers will be much fasters than the compilers ,so why do you worry about speed?
I'm more curious to know if Gas optimizes code size as well as Fasm.
If you are a compiler developper and want to get maximum speed ,then your
compiler should directly generate the executable without using any assembler or linker.

28 Mar 2008, 11:23

CBB

Joined: 28 Feb 2008
Posts: 7

CBB 28 Mar 2008, 17:52

Code:

Last edited by CBB on 31 Mar 2008, 22:09; edited 1 time in total

28 Mar 2008, 17:52

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 29 Mar 2008, 07:52

What compiler output did you use for NASM? I mean, maybe you could mostly use GCC's -masm=intel with a few macros, but I've never tried (too tedious). However, YASM has a GAS preprocessor which works without change in most cases, and YASM is definitely faster than NASM (even their latest). However, I dunno how to automatically use YASM instead of GAS because it needs "-p gas -f elf" (or whatever).

Anyways, the real slowdown will be depending on what compiler and OS you use. Also, too many separate modules can slow you down too. (ADOM at one time claimed to need thrice as long to compile on DOS as Linux although I bet even that could be sped up ... but it's closed src, so I can only guess.) If you use GCC, -O is much faster than -O2. And a good cache helps (for DOS anyways, most others probably have their own on by default). If you compile on a RAM drive and have your %TMPDIR% point to there, that helps too. I've noticed that older GCCs are much faster (e.g. 2.95.3, less optimizations??), but if you use a UPX'd version (e.g. on XP or Vista), it's actually slower than unpacked (unlike pure DOS). I think DJGPP / GCC 3.44 runs slower on my AMD64x2 than my P4 (although with newer GCCs it's the reverse). So, it could be anything.

I still suggest you recompile NASM or YASM with -march=native to see how much that helps. (Oh, and don't knock 10% improvement: it adds up.)

29 Mar 2008, 07:52

CBB

Joined: 28 Feb 2008
Posts: 7

CBB 29 Mar 2008, 14:17

Code:

Last edited by CBB on 31 Mar 2008, 22:10; edited 1 time in total

29 Mar 2008, 14:17

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 29 Mar 2008, 18:35

CBB wrote:

Hi rugxulo,

thanks for your constructive replies, I appreciate it!

In other words, I was saying it depends on your setup as much as what software you use. BTW, what OSes and cpus are you mainly using (in general)? Anything common (WinXP, Linux) or just some more proprietary stuff??

Quote:

Quote:
However, YASM has a GAS preprocessor which works without change in most cases, and YASM is definitely faster than NASM (even their latest).

I have briefly looked into yasm as well, but when I tried it, I didn't find it to be MUCH faster than nasm (I cannot tell you numbers, but I think I perceived it as being almost the same speed as nasm, maybe that has changed?), so I ended up classifying it as 'slow' as well. I do give yasm credit for various advanced features that are not (or weren't) present in nasm though.

Well, it is faster, but on newer machines it may not seem as much. The more you use it, though, the more it will add up. BTW, in testing in general on my old P166 last night, the latest NASM (without optimizations) is noticeably faster than pre-0.98 NASMs. And honestly, NASM without optimizations is faster than YASM, but YASM always optimizes displacements and comparing that to NASM -Ox, it easily wins, hands down.

Quote:

These are good ideas, but they do not really apply to my case.

I am trying to speed up every possible compilation, including optimised builds.

If you have a hundred separate modules, it's always going to be slower than fifty because the compiler has to run twice as much.

make -j2 (or -j4, whatever)
'kill -9' (or Vista's 'taskkill') some unneeded background processes
recompile GCC for your main processor (-march=native)
distcc or ccache (no idea, never tried it)
upgrade your OS
buy more RAM
buy a Mac Pro Intel Core 2 Quad "Penryn" x2

Quote:

As I said, nasm was 5 or 6 times slower than gas for me, so I don't really want to go back and benchmark whether compiler flags buy me a few more percent.

GAS is meant to (mostly) only be a backend, so it's supposed to be fast. You may have tapped its potential. But do try the latest NASM (recompiled) without optimizations for comparison.

Quote:

Some here think I believe that switching assemblers will solve all of my performance problems ever, forever. In reality, however, I'm just looking at a particularly quick way (but not necessarily cheap and easy in the long run) to get some more speed.

Tomasz knows what he's doing, and FASM is darn fast. And you have the source, so tweak away! Seriously, though, GAS and FASM have different goals, so they can't really be truly compared to each other.

Actually, you may have better luck just using e.g. GCC 3.4.4 instead of 4.3.0 (less optimizations but still pretty good and faster) or even (gasp) an entirely different compiler (e.g. OpenWatcom). Don't stay stuck to GCC so fiercely that you neglect the alternatives.

BTW, try "gcc -v -Q -O2" and you'll see all the millions of optimizations it tries to use. If you can somehow narrow it down to what really helps (and what doesn't), you could manually tell GCC to (only) use those instead of trying everything and the kitchen sink.

Quote:

However, I'd still be interested in numbers that compare fasm and gas speed.

I'm sure other people can help you there, but I usually don't use FASM for GCC. But it is indeed fast. Still, it's way more apparent on a 486 than it is on a P4. So, you're fighting a losing battle if you only run it on "top of the line" hardware because its less impressive that way.

29 Mar 2008, 18:35

CBB

Joined: 28 Feb 2008
Posts: 7

CBB 29 Mar 2008, 19:03

Code:

Last edited by CBB on 31 Mar 2008, 22:10; edited 1 time in total

29 Mar 2008, 19:03

MichaelH

Joined: 03 May 2005
Posts: 402

MichaelH 31 Mar 2008, 00:30

CBB wrote:

yasm is taking 0.7 seconds and nasm 0.5 seconds for my test case. gas is taking 0.08 seconds.

Well that's to be expected, after all they are both written in c\c++ code ..... wouldn't you agree f0dder Smile

CBB wrote:

gas is taking 0.08 seconds

Seems a bit slow. How many include files, lines of code and output size is this test?

Here is the output of my fasm stripped tweaked, and feature added assembler I call casm

AMD sempron 3100+ (1800)

Code:

casm assembling casm
18 include files + 1  binary  file
approx 18700 lines of code
4 passes, 49953 bytes.

0.00023299     initialise
0.00499281        preprocessor
0.01836351      parser
0.02692577    assembler
0.02726436 formatter
0.02739734 end

Code:

fasm assembling casm
18 include files + 1  binary  file
approx 18700 lines of code
4 passes, 50688 bytes.

0.00027657 initialise
0.00855304        preprocessor
0.02784544      parser
0.03780005    assembler
0.03784727 formatter
0.03831716 end

Code:


casm assembling fasm 

13 include files
approx 22500 lines of code

output 72981 bytes

0.00000000      casm
0.00023327      initialise
0.00656257        preprocessor
0.02640475      parser
0.04021042    assembler
0.04067109 formatter
0.04119881 end

Code:


fasm assembling fasm 

13 include files
approx 22500 lines of code

output 80384 bytes

0.00027015  initialise
0.01435406        preprocessor
0.04313286      parser
0.05916171    assembler
0.05920920 formatter
0.05976570 end

Casm approx 30 percent faster than fasm .... still a lot more improvements available

Last edited by MichaelH on 31 Mar 2008, 03:11; edited 2 times in total

31 Mar 2008, 00:30

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system

revolution 31 Mar 2008, 00:59

CBB wrote:

But it looks like I'll have to find it out myself...

Well when one embarks on a project where only one person is involved then I guess one needs to expect that.

31 Mar 2008, 00:59

Octavio

Joined: 21 Jun 2003
Posts: 366
Location: Spain

Octavio 31 Mar 2008, 06:35

MichaelH wrote:

Casm approx 30 percent faster than fasm .... still a lot more improvements available

And where is it?
url?

31 Mar 2008, 06:35

MichaelH

Joined: 03 May 2005
Posts: 402

MichaelH 31 Mar 2008, 08:16

Quote:

And where is it?

Hi Octavio, strange you're asking that, I thought octasm was the best assembler there is Wink

First up it's still Tomasz copyrighted code so perhaps it will never be released.

Also as I said, still a lot more improvements available and very badly needed before even considering releasing anything.

My post was really just to show CBB that fasm is very fast, perhaps way faster than all out there.

Waiting to see what CBB test parameters for his gas tests were.

31 Mar 2008, 08:16

Octavio

Joined: 21 Jun 2003
Posts: 366
Location: Spain

Octavio 31 Mar 2008, 12:25

MichaelH wrote:

Quote:

And where is it?

Hi Octavio, strange you're asking that, I thought octasm was the best assembler there is
.

I know Fasm is not the fastest 16-32 bit assembler A86 and Octasm are much faster but the first post was about 64 bit assemblers.
What i found interesting in your post is that you claim that casm generates code 2% smaller than Fasm ,and i thinked that Fasm was the best at code size optimization.

Last edited by Octavio on 31 Mar 2008, 21:24; edited 1 time in total

31 Mar 2008, 12:25

Goto page Previous 1, 2, 3 Next

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum