flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
JohnFound 01 Jun 2004, 00:19
Hi all.
These days I implemented these macroses in the project Fresh and converted almost all string constants to this format. Unfortunately there is one big problem with this macro set - the compiler speed decrease as far as twice: Without constant macroses: Total time: 18.023s preprocessing: 6.822s Parsing: 1.321s Assembling time: 8.569s (79 passes) With constant macroses: Total time: 42.867s preprocessing: 21.242s parsing: 3.099s Assembling time: 17.057s (79 passes) So, I find these macroses highly useful, but the performance degradation is too big to be appropriate... Some ideas?... Regards. |
|||
![]() |
|
comrade 01 Jun 2004, 02:43
get a faster computer
|
|||
![]() |
|
JohnFound 01 Jun 2004, 02:47
comrade wrote: get a faster computer Even on faster computer twice slower will be twice slower. ![]() |
|||
![]() |
|
decard 01 Jun 2004, 13:53
further optimizations to preprocessor? (if they're possible)
and why assembly time has increased? macros are processed by preprocessor, aren't they? |
|||
![]() |
|
JohnFound 01 Jun 2004, 14:04
decard wrote: further optimizations to preprocessor? (if they're possible) There is "if text in <strings> " operator, that will be processed in assembly stage. This macroses are interesting namely with loading equally preprocessor and assembler ![]() |
|||
![]() |
|
Tomasz Grysztar 01 Jun 2004, 15:03
Processing the "eq" and "in" comparisions in parser instead of assembler is already on the TODO list (also, if conditional expression can be evaluated without doubt at the parsing stage, the whole "if" block should be processed at this stage). However, I cannot promise I'll be able to implement it very soon.
|
|||
![]() |
|
JohnFound 01 Jun 2004, 16:18
Privalov wrote: Processing the "eq" and "in" comparisions in parser instead of assembler is already on the TODO list (also, if conditional expression can be evaluated without doubt at the parsing stage, the whole "if" block should be processed at this stage). However, I cannot promise I'll be able to implement it very soon. Yea, this is good idea, because it will remove processing from multipass assembly stage, but IMHO, this can't solve above constants definition problem. Using this macro leads to every next defined string constant checks all previously defined constants - that leads to O(n^2)... Regards |
|||
![]() |
|
Tomasz Grysztar 01 Jun 2004, 17:09
You might try adding some hash calculation for faster comparisions - fasm's assembly-time "repeat" and "if" abilities allow it.
Or you can add an option to disable those check for the work stage compilations, and enable it only for final assembly, when you need to get the optimized executable. |
|||
![]() |
|
S.T.A.S. 02 Jun 2004, 16:14
Hmm.. if text in <strings> is used (I hope) to speed up the macro.
Slow forward block should only be processed if string is already defined earlier. I guess this set of macro is a bit lame ![]() Unfortunately, my computer is rather fast and my projects are quite small to notice real speed difference in variants ![]() And one thing (it's offtopic, but has some relation to compiling speed) One frend of mine send me a mail with nearly such content (sorry for translation): Quote:
I did the same test with: FASM v1.52 console, Windows XP Home SP1, AthlonXP2000+ @1667Mhz, 512Mb DDR266. My results differ a lot: For the first test 0.8с & 0.3с. And 0.4с & 0.3с for the second. I think there are lot of things that affects such tests and tests are too synthetic, but these examples show that smal changes in macros could give noticeable results. Too bad I'm not good with FASM internals to understend such details and use the power ![]() |
|||
![]() |
|
revolution 31 Aug 2004, 07:10
One thing I noticed with a similar macro I was using for a while was that for a large project I was working with the assemble time would gradually increase as I added more strings to the list. But eventually the project became too complex and the command line version of fasm gave up with out of an out of memory error.
I had to abandon the macro and manually make each string with a label then alter all places I was using the string. In fact I used it with my invoke macro so that strings were reused if more than one invoke statement had the same string constant in it. The actual size of the executable at the time the memory error came up was only 33k. At the time my machine had 512Meg on-board but by using the task manager I noticed that fasm was allocating only ~256Meg before failing. |
|||
![]() |
|
JohnFound 31 Aug 2004, 09:45
Unfortunately, the comparisons with previous defined strings, in order to prevent duplications, uses very bad algorithm with speed O(n^2). So, the compilation speed decrease very fast with increasing string count.
That was the reason I refused this check in Fresh library and now Fresh simply defines every string without checking. The result is only several hundreds bytes of duplicated data and at least twice faster compilation. Of course we need such constants data definitions, but IMHO, we need some new approach to it. Regards. |
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.