flat assembler
Message board for the users of flat assembler.

Index > Main > Compilation speed

Author
Thread Post new topic Reply to topic
ChrisLeslie



Joined: 04 Jun 2006
Posts: 50
Location: Australia
ChrisLeslie
In order to learn more about FASM I had set myself to writing a little exercise project in FASM. I started with developing a suite of useful macros and procs. As the project grew in size the compilation time became longer and longer until I was waiting up to 52 seconds for compilation to finish - time to go and get a cup of tea! My computer is an unfortunately and old 32Meg laptop, but 52 seconds seemed unreasonable.
Then I replaced the win32 header "win32ax" with manual headers and an import data section and the compile time went down to about 30 seconds - almost twice as fast but still time to have a yawn!
Then I replaced all of the .if/.while macros with a set of simple "doif" and "loopif" on condition macros that I had been working on previously and the compile time went down to about 6 seconds - almost 10 times as fast!!! Therefore, I shall likely be doing things more manually in the future when using FASM, at least when using an old computer. Perhaps my use of the headers and HLL macros was not optimal? Is this situation surprising to forum members, or is it expected?

Regards

Chris Leslie
Post 23 Aug 2006, 02:03
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
There was too much swapping or just too much CPU usage?
Post 23 Aug 2006, 02:42
View user's profile Send private message Reply with quote
RedGhost



Joined: 18 May 2005
Posts: 443
Location: BC, Canada
RedGhost
I have never had fasm take more than like 1 second to compile anything but I have a very fast computer Confused

Perhaps the preprocessor logic takes more time than just assembling instructions Smile

_________________
redghost.ca
Post 23 Aug 2006, 04:15
View user's profile Send private message AIM Address MSN Messenger Reply with quote
ChrisLeslie



Joined: 04 Jun 2006
Posts: 50
Location: Australia
ChrisLeslie
Quote:
There was too much swapping or just too much CPU usage?

Judging from the amount of disk activity I think it was continually swapping to disk. Did not check CPU useage. After all it is running on Win95! with 32Meg so that is likely the reason.
If I compile on my fast computer at work (after shoowing away the kangaroos from the front door and without the boss knowing!!) it is very fast as normal. But I think I will still continue to program at a lower level for my excercise.

Chris
Post 23 Aug 2006, 04:30
View user's profile Send private message Reply with quote
dead_body



Joined: 21 Sep 2005
Posts: 187
Location: Ukraine,Kharkov
dead_body
you may download fasmpre.exe and see what are wrong in your macroses, and why they are so slow.
Post 23 Aug 2006, 08:07
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
With extensive use of the macros it's quite normal - especially as heavy ones as win32ax (which from the beginning were then ones where the features are more important than speed). However I still use some of the macros in the fasmw sources, even though I sometimes compile it on old P60 machine.
On the other hand - the first versions of fasm were self-compiling in about few minutes on the 386 processor - and I already thought it was fast! Wink
Post 23 Aug 2006, 08:39
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
it is expected, those macros are "doing everything for you smart-way", and that, performed in "interpreted scripting language" of course is very slow.

As tomasz said, those macros are for functionality, at cost of speed. One great advantage of FASM is that you can always make thing yourself and you don't have to use higher level constructs.
Post 23 Aug 2006, 10:45
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Since he said that there was too much disk activity the problem here was that FASM has used more than the physical available memory and disk accesses are a lot of times slower than RAM accesses.
Post 23 Aug 2006, 12:15
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
good point, try to decrease FASM memory to minimal needed value
Post 23 Aug 2006, 12:17
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
ChrisLeslie



Joined: 04 Jun 2006
Posts: 50
Location: Australia
ChrisLeslie
The slowness was coming from an over use of macros, with way too much macro nesting. I have proceduralised much of the application and now the compilation speed is normal, even with with the Win32 headers and Tomasz's .if macros. This is a lesson for me to avoid going overboard with macros when designing an application. The situation is not so apparent with a fast computer, but I would rather solve a problem with technique rather that resorting to a faster computer!

Thanks for all the support.

Chris
Post 12 Sep 2006, 08:57
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Well, you are to be congratulated since most people (myself included) often just "do what works" even if there is a faster way. We need to break this habit and keep pushing ourselves to improve, especially with tasks that we perform often (e.g., compression, re-assembling, etc.). But, often there are no easy solutions.

For example, ZOO 2.01 (zoo a mytest *.txt) is faster than ZOO 2.10 doing the same thing. Why? I dunno, but if speed is important, use 2.01.

Also, four different HA variants I tried (HA C--, HA NT, HA DOS, and LGHA) all performed differently. (See here for Matt Mahoney's compression benchmark).

I know of several timing utils (first is Win32-based, others are DOS):
Timer, UPCT, RunTime, and DJGPP's Redir.

P.S. ChrisLeslie, if you still have the old macro-bloated version of your project, try it under pure DOS with FASM (DOS version), and see if the time is still 30+ secs.
Post 12 Sep 2006, 15:25
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Quote:

For example, ZOO 2.01 (zoo a mytest *.txt) is faster than ZOO 2.10 doing the same thing. Why? I dunno, but if speed is important, use 2.01.

Better compression ratio in ZOO 2.10?
Post 12 Sep 2006, 22:12
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
f0dder, there does seem to be a (very very) small improvement (< 2k, in my wimpy test) in the default compression method in 2.10 vs. the older 2.01, but I hardly think this warrants more than double the compression time. Razz

<EDIT>
I'm not talking about the new high compression method introduced but the old standard compression method.
</EDIT>
Post 12 Sep 2006, 23:58
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:  


< 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.