Index
> Programming Language Design > FASM/G Build Performance - I Surmise not an Issue |
| Author |
|
|
bitRAKE 31 Dec 2025, 00:22
If build times were an issue, initial startup for a particular environment could be cached as part of the system support -- the same could be done for fasm, too. (Analogous to the pre-compiled headers, [s]ccache, modules of the high-level languages.) To my knowledge, no such effort has ever been made.
|
|||
31 Dec 2025, 00:22 |
|
|
Greg_M 31 Dec 2025, 21:25
Post from 2020. May cause concern for those considering FASM/G?
Quote: ...I don't use fasmg because it is too slow. I have to wait almost an hour to complete a compilation set... https://board.flatassembler.net/topic.php?t=21488 It is from 2020, so perhaps improved now and/or perhaps when understood in the context, it's not an issue at all, hence my OP. |
|||
|
31 Dec 2025, 21:25 |
|
|
revolution 31 Dec 2025, 22:50
For my use case fasmg is considerably slower than fasm and does cause anguish. There is a trend in software development to add more layers of abstractions and hobble code with more "baggage" making it slower and more resource hungry. I have a fast computer, dammit, I don't want to make it slower each time new code comes along. Other examples of this effect are MS Teams and all the electron apps.
In addition to performance is the extras that fasmg needs to make it a complete assembler with all the required extra supporting macro files. Zipping up a project with asm sources and the assembler and sending it as a stand-alone package to a another customer/client/user requires also sending all the extra support macros along with it to make a complete set. It complicates the process and clutters up the package with extra bloat. For small projects with a single asm source file the bloat is very noticeable and degrades the experience, compared to needing only one exe for the single asm when using fasm. Keeping older versions available for fasm is easy, we just have each exe file with the version number appended to the filename, so assembling old code is straightforward. Supporting simultaneous older versions in fasmg needs a lot more work to setup separate folders to hold all the macros and have ways to specify those folders when assembling with different versions. That is my experience with fasmg. |
|||
|
31 Dec 2025, 22:50 |
|
|
Greg_M 31 Dec 2025, 23:36
revolution wrote: ...does cause anguish. revolution wrote: There is a trend in software development to add more layers of abstractions and hobble code with more "baggage" making it slower and more resource hungry. Other examples of this effect are MS Teams and all the electron apps. revolution wrote: In addition to performance is the extras that fasmg needs to make it a complete assembler with all the required extra supporting macro files. Zipping up a project with asm sources and the assembler and sending it as a stand-alone package to a another customer/client/user requires also sending all the extra support macros along with it to make a complete set. It complicates the process and clutters up the package with extra bloat. Last edited by Greg_M on 01 Jan 2026, 02:59; edited 1 time in total |
|||
|
31 Dec 2025, 23:36 |
|
|
revolution 01 Jan 2026, 00:35
fasmg doesn't compile C code. And C compilers don't assemble asm sources. I don't see how those can be compared in a meaningful way.
 |
|||
|
01 Jan 2026, 00:35 |
|
|
Greg_M 01 Jan 2026, 01:29
revolution wrote: fasmg doesn't compile C code. And C compilers don't assemble asm sources. I don't see how those can be compared in a meaningful way. :?: |
|||
|
01 Jan 2026, 01:29 |
|
|
bitRAKE 01 Jan 2026, 03:10
revolution wrote: C compilers don't assemble asm sources. Compiler drivers do process/assemble asm sources. For GCC the assembly tooling is separate, but Clang has an integrated assembler (which can be bypassed for the traditional external tool). This impacts both inline assembly and stand-alone files. MSVC is a different beast - no inline assembly support - must use intrinsics or external assembly code. In that regard you are completely correct, but the other cases are more complicated as the compiler driver makes assembly integration seamless with other language support. Yet, I agree with the comparison to fasmg being largely invalid. fasmg is somewhere between the compiler drivers and monolithic translators (fasm, tcc, etc.). _________________ ¯\(°_o)/¯ AI may [not] have aided with the above reply. |
|||
|
01 Jan 2026, 03:10 |
|
|
Greg_M 01 Jan 2026, 19:06
bitRAKE wrote: ...I agree with the comparison to fasmg being largely invalid. I haven't received a clear and emphatic response that FASM/G builds are fast, if not very fast, relative to general tools. FASM/G and its application of math theory for customizable/flexible code, does appear powerful for language development. I'm developing a new language, a hybrid of C-like and functional programming, and had been considering a tool to use, and FASM/G and C are both tools that support compiler development. I also see that the board description here states: "...for users of flat assembler" and doesn't include "for prospective users" so perhaps this isn't the right board for questions like mine, and if not, I apologize for distracting with off-topic posts. |
|||
|
01 Jan 2026, 19:06 |
|
|
revolution 01 Jan 2026, 20:31
Greg_M wrote: I haven't received a clear and emphatic response that FASM/G builds are fast ... If there is a specific test that can be constructed, then some sort of comparison might be doable, but it would only apply to that case. Other situations can give different results. So giving a single "emphatic" response of X is faster then Y is tricky. I suggest to test it, and use it where the use cases shows an advantage, and avoid it in cases where there is a disadvantage. There is no authority that can "emphaticly" and unambiguously state that fasmg is "faster", or that it is "slower", or indeed any speed comparison, because it depends upon the situation. I gave my anecdote above for my use cases, that fasmg is slower than fasm. That might mean nothing for the use case described in the OP when compared to C. Although it still isn't clear to me how such a comparison to C can be made. Providing more details on that would be appreciated. |
|||
|
01 Jan 2026, 20:31 |
|
|
Greg_M 01 Jan 2026, 23:01
revolution wrote: Although it still isn't clear to me how such a comparison to C can be made. Providing more details on that would be appreciated. |
|||
|
01 Jan 2026, 23:01 |
|
|
revolution 02 Jan 2026, 00:00
fasm is an an assembler, I use it to assemble assembly code. C is an HLL compiler, I use it to compile HLL code. So both are used. It isn't a one or the other thing.
I still can't see how to compare C to fasmg. Is it intended that fasmg uses a set of macros to compile HLL C code? Or is the intention to use C to assemble asm code? Or a mixture of both, somehow, and see which is the fastest? |
|||
|
02 Jan 2026, 00:00 |
|
|
Greg_M 02 Jan 2026, 01:06
Perhaps FASMG, with a "library" of user-defined Compiled-Assembly-Like-Macro instructions could be comparable to C in productivity and yet still have faster build times.
Last edited by Greg_M on 02 Jan 2026, 03:18; edited 1 time in total |
|||
|
02 Jan 2026, 01:06 |
|
|
Greg_M 02 Jan 2026, 02:52
bitRAKE wrote: If build times were an issue, initial startup for a particular environment could be cached as part of the system support -- the same could be done for fasm, too. (Analogous to the pre-compiled headers, [s]ccache, modules of the high-level languages.) To my knowledge, no such effort has ever been made. If so, I better understand your point now, thank you. |
|||
|
02 Jan 2026, 02:52 |
|
|
bitRAKE 02 Jan 2026, 16:27
bitRAKE wrote: fasmg is somewhere between the compiler drivers and monolithic translators (fasm, tcc, etc.). If we wanted to have a meaningful test of performance there are plenty of libraries of assembly functions - these would be adapted for building with various tools. It takes existing public use cases and restricts all the tools to this subset of functionality -- unfair by design. Don't experienced people already know the result of this test though? Greg_M wrote: Is this related?: https://board.flatassembler.net/topic.php?t=24110 My recommendation would be to read the source code - understand the core and the system interface. _________________ ¯\(°_o)/¯ AI may [not] have aided with the above reply. |
|||
|
02 Jan 2026, 16:27 |
|
|
Greg_M 02 Jan 2026, 21:29
bitRAKE wrote: My recommendation would be to read the source code - understand the core and the system interface. |
|||
|
02 Jan 2026, 21:29 |
|
|
AsmGuru62 02 Jan 2026, 21:51
Can you define "memory safe" term?
What does it mean exactly? A link to the language design would be nice. |
|||
|
02 Jan 2026, 21:51 |
|
|
Greg_M 02 Jan 2026, 22:24
AsmGuru62 wrote: Can you define "memory safe" term? https://www.cisa.gov/sites/default/files/2023-12/CSAC_TAC_Recommendations-Memory-Safety_Final_20231205_508.pdf AsmGuru62 wrote: A link to the language design would be nice. https://github.com/McPherran/Programming-Language |
|||
|
02 Jan 2026, 22:24 |
|
< Last Thread | Next Thread > |
Forum Rules:
|