flat assembler
Message board for the users of flat assembler.
![]() Goto page 1, 2 Next |
Author |
|
nmake 11 Mar 2013, 18:02
Newest release compiles about 5 times faster. I don't know why, but it's a good thing.
![]() |
|||
![]() |
|
revolution 11 Mar 2013, 21:34
Compiles what 5 times faster? How is this related to the website feedback forum?
|
|||
![]() |
|
Bob++ 11 Mar 2013, 22:30
What compiler? :O
|
|||
![]() |
|
revolution 12 Mar 2013, 09:05
Moved to main.
|
|||
![]() |
|
baldr 12 Mar 2013, 10:05
nmake,
Is it a stable and reproduceable effect? |
|||
![]() |
|
nmake 12 Mar 2013, 10:16
baldr, it is stable, it happens when i click the run button in the compile menu with one of my direct3d apps. The program compiles and runs instantly, in the 1.71.07 it took anywhere from 1 to 6 seconds for the program to even start after clicking the run button and this happened every time. Anti virus programs can interfere here, but it should not be the case with fasm afaik because a newer fasm shouldn't be any more recognized by the AV than an older one. Small but insignificant detail, but it just compile and runs faster. No idea why
![]() |
|||
![]() |
|
baldr 12 Mar 2013, 11:48
nmake,
Does it happens with command-line version too? To be thorough, you may run it several times, taking in account trailing ones (due to warm-up). Heh, it runs faster? Either a spontaneous γ-quantum, or gods had smiled upon you. ![]() |
|||
![]() |
|
nmake 12 Mar 2013, 12:00
If it is so, then this y-quantum had a reproducable effect with version 1.71.07 and completely gone in version 1.71.08. The run command compiles and runs at the same time. I haven't checked the command line option because I've upgraded now and don't want to roll back. I use tools to check which files are changed and them copy them manually, too much work to roll back now.
|
|||
![]() |
|
revolution 12 Mar 2013, 12:06
You can extract just 'fasm.exe' from the older archive to a new folder and run from there. No need to overwrite your current installation.
Although I struggle to understand why you don't simply extract the whole archive each time. Why do so much work with the manual copying? |
|||
![]() |
|
nmake 12 Mar 2013, 12:09
revolution, the archive updates include files, I have updated my include files to be complete. tomasz release include files that approach the completeness I have made my own, mine is complete, and his include files approach completeness at a slow pace, and the fasm.exe is not used in the same way fasmw compiles, althought they both use the same source, they compile separately. The way fasm.exe compiles is not necessarily reproducable in the way fasmw.exe compiles.
I copied fasmw.exe of the old version back to the folder and hit the run button again, now it compiles at 1 second each and every single time. I then copied back the newest fasmw.exe and now when I hit run button it compiles and run instantly, no wait, every time. Don't ask me why ![]() |
|||
![]() |
|
baldr 12 Mar 2013, 12:41
nmake,
07/08 INCLUDE differences are negligible (unless your program is gesture-oriented). |
|||
![]() |
|
nmake 12 Mar 2013, 13:00
Everything is negligible until you need it. There is also a large gap in equations missing, and not just for gestures.
|
|||
![]() |
|
baldr 12 Mar 2013, 13:43
nmake,
I mean, if your program compiles with 1.71.07 INCLUDES fine, differences are negligible. Happy trolling! ![]() |
|||
![]() |
|
nmake 12 Mar 2013, 14:30
Only a very small portion is different from 07 to 08
![]() |
|||
![]() |
|
revolution 12 Mar 2013, 14:42
Could it be some sort of alignment thing? Accessing unaligned data can and does cause a difference when compared to aligned data. Although I would not have expected 5x speed-up, but still possible I suppose if one goes from worst case misalignment to best case alignment.
|
|||
![]() |
|
nmake 12 Mar 2013, 15:19
I located all changes in fasmw.asm to new fasmw.asm, here are all changes
These pieces of code exist only in new fasmw.asm #1 Code: _user_library db 'USER32.DLL',0 _setgestureconfig_api db 'SetGestureConfig',0 _getgestureinfo_api db 'GetGestureInfo',0 _closegestureinfohandle_api db 'CloseGestureInfoHandle',0 #2 Code: SetGestureConfig dd 0 GetGestureInfo dd 0 CloseGestureInfoHandle dd 0 #3 Code: invoke GetModuleHandle,_user_library or eax,eax jz gesture_api_unavailable mov ebx,eax invoke GetProcAddress,ebx,_setgestureconfig_api or eax,eax jz gesture_api_unavailable mov esi,eax invoke GetProcAddress,ebx,_getgestureinfo_api or eax,eax jz gesture_api_unavailable mov edi,eax invoke GetProcAddress,ebx,_closegestureinfohandle_api or eax,eax jz gesture_api_unavailable mov [CloseGestureInfoHandle],eax mov [SetGestureConfig],esi mov [GetGestureInfo],edi gesture_api_unavailable: #4 Code: GetLastError,'GetLastError',\ #5 Code: dialogitem 'STATIC',<'flat assembler ',2014h,' version ',VERSION_STRING,0Dh,0Ah,'Copyright ',0A9h,' 1999-2013 Tomasz Grysztar.'>,-1,27,10,144,40,WS_VISIBLE+SS_CENTER #6 Code: 'LegalCopyright',<'Copyright ',0A9h,' 1999-2013 Tomasz Grysztar.'>,\ There seems to be little to dig into here ![]() No changes in assemble.inc (except for copyright info) No changes in parser.inc either (except for copyright info) All source files in Source/IDE stay the same (except for copyright info) I am going to have to just accept that this must be related to, what revolution referred to, perhaps a change of alignment, some other hardware related issues, an antivirus program that is unpredictable, or any other issues. Whatever the cause is. I could have posted the source code I tested with, but I have scattered include files, it wouldn't compile well on other machines. I think I will only conclude that this must be a local phenomenon. |
|||
![]() |
|
JohnFound 12 Mar 2013, 16:49
I can't reproduce this effect with Fresh IDE - there is no difference on big sources between 2.1.4 (uses FASM 1.71.06) and 2.1.6 (FASM 1.71.0
![]() |
|||
![]() |
|
AsmGuru62 12 Mar 2013, 16:54
Maybe the drive is fragmented and old version was put into fragmented space and new one is larger and gets into un-fragmented space?..
|
|||
![]() |
|
nmake 13 Mar 2013, 02:22
I did a new test, copied back the old fasmw.exe and did compile and run 20 times. The first 10 times I did not delete the executable.
About 1 second About 1.2 seconds About 1 second About 0.9 second About 0.8 second About 1.2 second About 0.8 second About 1.2 second About 0.9 second About 0.9 second The last 10 times I deleted the executable just to force it to recompile when I hit run button and the timings were the same as the timing above here, but a few times with a slight increase in compile time, it went up to 2.1 second at a maximum, but never below the timings above. Then I took back the newest fasmw.exe again and did the test an equal amount of times and it ran and compiled instantly. 1(+-) second compile time for a 14 kb source file is a lot. The effect is stable. Turned off firewall and antivirus, the effect is still there. command-line compiling with old and new fasm.exe produce the same timing. Only fasmw.exe produce this effect. fasmw use 65535 amount of memory in the compiler setup and fasm.exe reports a large amount of memory when compiling, I don't know if this is the amount it uses, but it is considerably larger than 64 kb. I increased memory in compiler options to 524288 bytes, and it had no effect on the timings above here. It actually increased to 3 seconds at a maximum in one of the tests. The newest fasmw run and compile instantly, no matter what memory setting it has. |
|||
![]() |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2023, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.