flat assembler
Message board for the users of flat assembler.

Index > Main > How fast is it really?

Goto page 1, 2, 3  Next
Author
Thread Post new topic Reply to topic
CBB



Joined: 28 Feb 2008
Posts: 7
CBB
Code:
    


Last edited by CBB on 31 Mar 2008, 22:08; edited 1 time in total
Post 28 Feb 2008, 21:46
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
Randall Hyde had once written a dedicated benchmark for testing the speed of various assemblers, look here.
If you wanna see some of the test results that was made for fasm (and some speedups that were done), look into this thread.
However I haven't benchmarked the latest fasm's versions yet.
Post 28 Feb 2008, 21:57
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> and gas uses one that is a bit easier to parse.

GAS has been supporting "intel syntax" also for 11 years. Very Happy

> Randall Hyde had once written a dedicated benchmark for testing the speed of various assemblers, look here.

Link is broken. Sad
Post 02 Mar 2008, 07:20
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
The original link may have been broken, but the benchmark was posted as an attachment in the second thread I linked here (and the first thread metions this fact).
Post 02 Mar 2008, 08:59
View user's profile Send private message Visit poster's website Reply with quote
asmrox



Joined: 19 Jan 2008
Posts: 160
asmrox
thers no diffrence betwen fasm and other asemblers. They all output same code, only syntax differ.
Post 02 Mar 2008, 10:30
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17663
Location: In your JS exploiting you and your system
revolution
asmrox wrote:
thers no diffrence betwen fasm and other asemblers. They all output same code, only syntax differ.
Oh how true that is NOT!
Post 02 Mar 2008, 10:32
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
very not true.
if fasm cross a [esi+0], it will not generate a [esi+0], but a [esi], so, fasm parser is an optimal choice for asm coding.
Post 02 Mar 2008, 11:24
View user's profile Send private message Visit poster's website Reply with quote
asmfan



Joined: 11 Aug 2006
Posts: 392
Location: Russian
asmfan
2 edfed
I think it is a miss. Even typing "dword 0" fasm refuses to assemble (
Tomasz if U read it maybe it is possible to fix it?
Post 02 Mar 2008, 12:35
View user's profile Send private message Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
daniel.lewis
More or less, I'd argue the difference lies in the macros.

Some things like inlining functions is very hard to do well without some high level macros because you want to figure out which registers are best at compile time.

I'd actually be tempted to integrate a scripting language into a table-driven assembler. You could assembler and disassemble, and you'd be able to do alot more during compile time to make sure everything is exactly how you want it.

Extending the scripts, you could (easily?) make it a debugger too. : p

Just a casual thought.
Post 05 Mar 2008, 00:23
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3043
Location: vpcmipstrm
bitRAKE
FASM lacks the ablity to return a value from macro - inline macros are very useful. Sometimes EQU can be used, but usually a more complicated macro is needed and isn't visually appealing to me.

_________________
¯\(°_o)/¯ unlicense.org
Post 05 Mar 2008, 02:57
View user's profile Send private message Visit poster's website Reply with quote
rhyde



Joined: 03 May 2007
Posts: 21
rhyde
CBB wrote:
Hi,

fasm is supposedly one of if not THE fastest assembler around. Kudos!


Yes indeed.
However, do keep in mind that with the speed of today's machines, most assemblers will compile any reasonable-sized file instantaneously, so the speed advantage isn't that important anymore. Back in the days when it took 30 seconds to compile a file, assembler performance was very important. But most projects today will compile in under a second or two, so performance is really more of a "bragging right" than anything else.

Quote:

But, other assemblers such as gas are also fast. Has anyone done comparisons between fasm and gas? Or does anyone at least have an 'educated guess' as to how they compare?

As tomasz has pointed out already, I've done some of this in the past, but...


Quote:

I realise that this comparison is difficult because the assemblers use different syntax, and gas uses one that is a bit easier to parse.

Comparison is difficult, but not because of the "easier to parse" issue (which, quite honestly, isn't really true for Gas vs. FASM). Some assemblers (such as MASM, TASM, and HLA) are loaded with a lot of features that make them *much* larger that other assemblers and that has a much bigger impact on performance. Some assemblers (HLA) use crappy symbol table lookup functions, that has a much bigger impact on performance. One reason FASM is so fast, for example, is that it is quite small and the program fits entirely in cache (even on older machines). That has a *big* impact on performance compared with larger assemblers that are constantly moving data in and out of cache from main memory.

The real reason comparisons are difficult, however, is because assemblers vary greatly in their feature sets. For example, FASM, Gas, and NASM are all "low-level assemblers" that don't support HLL-like constructs like MASM, TASM, and HLA do. Sure, we could write programs in a subsets of these assembler's languages, but that's not how real MASM, TASM, and HLA programs are written. So would the comparison be valid? And even ignoring the HLL-like features some assemblers possess, almost every assembler out there has a different concept of macros. And macro expansion is one of the more expensive operations an assembler can do during compile time. Again, do we ignore the use of macros in our benchmark files? That wouldn't be very useful as most reasonable assembly language programs make use of macros.

Quote:

So let me add the following clarifications:

- Assume fasm and gas source asm files of about equivalent size
- Assume they do the same thing (ideally using identical instructions)
- Grant gas that little ease-of-parsing advantage it has and ignore it

Now, using these parameters, how fast have you observed both assemblers, or how fast would you expect them to perform?


Very simple. Just write a decent-sized HLA program and use the "-sf" and "-sg" command-line options to translate the program into FASM and GAS source code. While you're at it, you may as well do "-st" (TASM) and "-sm" (MASM), too.

I never ran the benchmarks against Gas, but in the past I have found the following approximate ordering by performance (fastest to slowest):

TASM
FASM
MASM
NASM

However, my results are very old. TASM has never been updated, but FASM, MASM, and NASM have been. YMMV.

Quote:

This question is very interesting to me because assembler performance can be important for compiler backends.

Less important than you think. HLA, for example, can use MASM, TASM, NASM (HLA v1.102), and Gas as "back-end assemblers". Given the simple (instruction-only) source output that HLA produces, there is almost no impact on compiler performance by the choice of assembler (well, with the single exception of MASM6 when you declare a large static array -- a known defect in MASM6).

To me, a bigger concern would be the support of the entire x86 instruction set. Currently, FASM has the best support for all the x86 instructions (even better than Gas). If you intend to use certain SSE instructions with today's versions of Gas and FASM, I think you're better off with FASM at this point. Then again, Gas will, no doubt, be updated before too much longer.

MASM and TASM are bad choices (OS-specific, continuing support issues). NASM is a good choice from an instruction set point of view (and it's actually getting support these days), but I've not measured the performance of NASM 2.02 so I don't know how much better the performance is than it was back in the NASM 0.98 days (which was really bad).

Quote:

I heard HLA compiles for fasm and gas, maybe that would be worth comparing??

Yes, that's how I've done it in the past.

Finally, are there any current x86/amd64 assemblers which are even faster than fasm?
[/quote]

The last time I ran benchmarks, TASM was faster. But not fast enough to justify using a closed-source/unsupported/32-bit-only/OMF-only/Windows-only program.
hLater,
Randy Hyde
Post 19 Mar 2008, 16:21
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Quote:
(well, with the single exception of MASM6 when you declare a large static array -- a known defect in MASM6).
And iirc only present for COFF and not OMF object files? (the COFF implementation could still be sped up though, and probably by a very large amount, although it does need to write all the bytes to disk).
Post 20 Mar 2008, 01:41
View user's profile Send private message Visit poster's website Reply with quote
rhyde



Joined: 03 May 2007
Posts: 21
rhyde
f0dder wrote:
Quote:
(well, with the single exception of MASM6 when you declare a large static array -- a known defect in MASM6).
And iirc only present for COFF and not OMF object files? (the COFF implementation could still be sped up though, and probably by a very large amount, although it does need to write all the bytes to disk).


Actually, I ran into some problems recently with the OMF->COFF conversion that the Microsoft linker does. Unless this problem has been resolved, I would be *very* careful about relying on that translation to fix the COFF generator performance problems.

In any case, I don't particularly recommend MASM as the back-end to a compiler. It has enough idiosyncrasies, plus the fact that the version that everyone has (v6) doesn't support much beyond the basic MMX instruction set, is a problem.

To the OP: One of these days I will post HLA v1.102 to http://webster.cs.ucr.edu. This version has a completely rewritten instruction parser and code generator. In particular, it supports hexadecimal output of all instructions as well as source output for MASM, TASM, NASM, Gas, and FASM. Though it was a *lot* of work to provide all the difference source code output formats, I feel that it's worth it. When HLA v1.102 comes out, you might grab the "output.c" source file (that contains all the code to emit all the various instructions in all the various output formats) and use that as a template.
Cheers,
Randy Hyde
Post 20 Mar 2008, 02:13
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
randy: looking forward for next release of library, so i can point out more bugs and design glitches Razz Wink
Post 20 Mar 2008, 02:56
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
daniel.lewis
The assemblers all seem to do it in <0.5s for <80kb source programs. At some point, doesn't it get trivial?

I concern myself more with features that will actually save me time. For the assembler itself, making it capable of flat and EIP-trace disassembly would save me alot of time.

For an IDE, being able to drag and drop snippets, have proper flow-control graphing, and register tracing and range graphing, and a forwards and backwards capable assembler at the back-end would make coding assembler easier than most HLL's.

I'd be willing to help. To be honest I find it sad that we create immersive 3d games but are still stuck typing text into a plain editor and running the command lines when we code.

Regards,
Dan
Post 21 Mar 2008, 00:07
View user's profile Send private message Reply with quote
rhyde



Joined: 03 May 2007
Posts: 21
rhyde
daniel.lewis wrote:
The assemblers all seem to do it in <0.5s for <80kb source programs. At some point, doesn't it get trivial?


Actually, I've been working on an HLA->NASM translator.
Compiling the FASM v1.66 source code (translated to HLA source code, which I use as a back-end for HLA), HLA reports 71593 lines of source code processed (after macro expansions). It compiles this in about 0.512 seconds or 139830 lines/sec (this is about half the speed of FASM measurements I've made). This produces almost 60,000 lines of NASM code with no macros. NASM v2.02 requires about 12 seconds to process the output.

I was told that NASM had been sped up considerably between the 0.98 release and the v2.02 release. However, performance could obviously be improved a bit as most other assemblers do the same thing in well under one second.

Quote:

I concern myself more with features that will actually save me time. For the assembler itself, making it capable of flat and EIP-trace disassembly would save me alot of time.

For an IDE, being able to drag and drop snippets, have proper flow-control graphing, and register tracing and range graphing, and a forwards and backwards capable assembler at the back-end would make coding assembler easier than most HLL's.

I'd be willing to help. To be honest I find it sad that we create immersive 3d games but are still stuck typing text into a plain editor and running the command lines when we code.

Regards,
Dan


Well, feel free to continue the FRESH project Smile
hLater,
Randy Hyde
Post 23 Mar 2008, 01:42
View user's profile Send private message Reply with quote
rhyde



Joined: 03 May 2007
Posts: 21
rhyde
vid wrote:
randy: looking forward for next release of library, so i can point out more bugs and design glitches Razz Wink


I'm afraid the next release will be a disappointment, then.
Currently, my plans for the next major release (assuming no show-stoppers in the meantime) is a port to Mac OSX. There really won't be much in the way of new code, new designs, or anything like that. Just a port.
hLater,
Randy Hyde
Post 23 Mar 2008, 01:43
View user's profile Send private message Reply with quote
rhyde



Joined: 03 May 2007
Posts: 21
rhyde
rhyde wrote:


Actually, I've been working on an HLA->NASM translator.
Compiling the FASM v1.66 source code (translated to HLA source code, which I use as a back-end for HLA), HLA reports 71593 lines of source code processed (after macro expansions). It compiles this in about 0.512 seconds or 139830 lines/sec (this is about half the speed of FASM measurements I've made). This produces almost 60,000 lines of NASM code with no macros. NASM v2.02 requires about 12 seconds to process the output.



I ran the 30,000+ line source file through FASM and it took about 0.1 seconds to process. So actually, FASM measures about 2.5 times faster than HLA, though FASM is processing very simple compiler output (versus HLA which is processing a lot of macro code). In any case, let's call the performance difference 2.5 times.

Whatever, I still would argue that if performance is a high priority, NASM is probably a bad choice for a back-end assembler. OTOH, if portability is a goal (that is, getting your compiler to run on as many OSes as possible), NASM is a good choice as it's available on more OSes than even Gas.
hLater,
Randy Hyde
Post 23 Mar 2008, 01:58
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17663
Location: In your JS exploiting you and your system
revolution
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.

Ah, sometimes life seems so confusing! Sometimes problems become advantages and advantages become problems.

If the whole world never used non-x86 CPU's then I wonder how much of daniel.lewis' vision would have come true?
Post 23 Mar 2008, 02:04
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
lol, I actually started ASM using NASM, then when I created my first program I realized NASM actually didn't make executables Smile.
Post 23 Mar 2008, 02:59
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 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


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.