Index
> Main > another speedupsGoto page Previous 1, 2, 3 Next |
| Author |
|
|
JohnFound 18 Feb 2005, 08:20
Embrance wrote: As i see thres a speed opmtimizasion of 30-150%(in some cses.) IMHO, more important is that now there is no clearly defined bottleneck in FASM architecture. Preprocessor was the last module that was not optimized for speed. |
|||
18 Feb 2005, 08:20 |
|
|
MCD 18 Feb 2005, 11:05
Sounds all very good. But in case where people want to use only 32bit 80x86 code and want to get rid of the 64bit extensions, how could they port these speed improvements into the old 32bit Fasm preprocessor/parser? Is there anybody who need such an only 32bit assembler thing?
|
|||
|
18 Feb 2005, 11:05 |
|
|
Tomasz Grysztar 18 Feb 2005, 11:10
Since the implementation of x86-64 long mode does not cause any performance reduction nor incompatibility and the executable growth is also not that much, such thing shouldn't be really needed.
|
|||
|
18 Feb 2005, 11:10 |
|
|
Madis731 18 Feb 2005, 11:53
HAHAA FASM kicked other assemblers before and now its time to make new diagrams like the ones between 1.50,1.51 somewhere in the forum - like how far have we gone with this speed and what about the linearity of the growth in time - is it still a bit exponential or has it gone even more linear?
|
|||
|
18 Feb 2005, 11:53 |
|
|
MCD 18 Feb 2005, 12:02
Madis731 wrote: HAHAA FASM kicked other assemblers before and now its time to make new diagrams like the ones between 1.50,1.51 somewhere in the forum - like how far have we gone with this speed and what about the linearity of the growth in time - is it still a bit exponential or has it gone even more linear? Donno, I guess the speed growth of software in general would best resembles to the logistic growth, but with some random elements in it. |
|||
|
18 Feb 2005, 12:02 |
|
|
Matrix 18 Feb 2005, 14:26
hy
executable growth? use som exe packer, fasm can be shrinked if you'd like, i have tested it. it can be well compressed. |
|||
|
18 Feb 2005, 14:26 |
|
|
decard 18 Feb 2005, 16:00
executable has grown just by a few kbytes, it is actually nothing...
|
|||
|
18 Feb 2005, 16:00 |
|
|
Embrance 18 Feb 2005, 16:03
JohnFound wrote: IMHO, more important is that now there is no clearly defined bottleneck in FASM architecture. Preprocessor was the last module that was not optimized for speed Bottleneck?You mean limit? Privalov wrote: Since the implementation of x86-64 long mode does not cause any performance reduction nor incompatibility and the executable growth is also not that much, such thing shouldn't be really needed. How much is this growth?Is it a standard or depends on how big the file prosesed is? |
|||
|
18 Feb 2005, 16:03 |
|
|
Tomasz Grysztar 18 Feb 2005, 16:52
Embrance wrote: How much is this growth?Is it a standard or depends on how big the file prosesed is? I mean the size of FASM executable. The size of output executables can be even smaller with new version sometimes, as I have also corrected the instruction optimization for one (rare) case. |
|||
|
18 Feb 2005, 16:52 |
|
|
Embrance 18 Feb 2005, 17:48
Oh,i thuog th files prodused form FASM!Good to know nothing is chnaged thought!
|
|||
|
18 Feb 2005, 17:48 |
|
|
madmatt 18 Feb 2005, 23:50
I put the 1.58 gui interface into the 1.59.3 folder, and it compiled into an fasmw.exe ok. But when I loaded in some of my source code, and tried to compile it, it gave me an out of memory error. Does anyone have the gui verion compiled yet?
|
|||
|
18 Feb 2005, 23:50 |
|
|
Tomasz Grysztar 19 Feb 2005, 00:17
Have you tried setting up more memory in a compiler options? Preprocessor eats a bit more of memory now.
|
|||
|
19 Feb 2005, 00:17 |
|
|
madmatt 19 Feb 2005, 10:29
Have ~280 mb to spare after windows loads, So I Set the memory option to 192mb, which should be quite plenty. Is it trying to allocate dos memory by mistake? Maybe this is it?
MadMatt |
|||
|
19 Feb 2005, 10:29 |
|
|
Tomasz Grysztar 19 Feb 2005, 11:40
Remeber to replace the
Code: include '..\..\x86.inc' in FASM.INC with Code: include '..\..\x86_64.inc' Maybe that was causing the problem. |
|||
|
19 Feb 2005, 11:40 |
|
|
madmatt 19 Feb 2005, 17:06
I guessed that much, It wouldn't compile if I didn't
 . I also had to use the %fasminc% for the win32a.inc includes, but I don't think this would cause the problem. Hopefully there is a quick fix, but if not, I'll just wait until the next release.  |
|||
|
19 Feb 2005, 17:06 |
|
|
iklin 20 Feb 2005, 04:37
madmatt wrote: I put the 1.58 gui interface into the 1.59.3 folder, and it compiled into an fasmw.exe ok. But when I loaded in some of my source code, and tried to compile it, it gave me an out of memory error. Does anyone have the gui verion compiled yet? I try to do so and for me it works fine. |
|||
|
20 Feb 2005, 04:37 |
|
|
madmatt 20 Feb 2005, 07:54
Have a working version now!
 I had to drop the includes into the folder, instead of just using %fasminc% into the old directory. Thanks for everyones help.  |
|||
|
20 Feb 2005, 07:54 |
|
|
madmatt 20 Feb 2005, 08:30
I Spoke too soon. I try an compile some of my Direct3d code and it crashes, other times it gives me an 'out of memory error', on version 1.58 everything works fine. I've included a crashdump by Dr. Watson so you can see where the crash happened. Look toward the bottom of the text.
|
|||
|
20 Feb 2005, 08:30 |
|
|
Madis731 20 Feb 2005, 10:28
Hi guys - I'll try once again:
I didn't mean executable growth, but EXPONENTIAL growth in TIME, when bigger projects are met - like somebody mentioned we might as well call it logarithmic growth. I want you to take a look at THIS: http://board.flatassembler.net/topic.php?t=854&postdays=0&postorder=asc&start=50 topic and see how FASM jumped from 1.50 to 1.51 - I think it would be fun to test the speed of FASMs different parts and put them in a graph where we can compare them with other versions and assemblers. |
|||
|
20 Feb 2005, 10:28 |
|
| Goto page Previous 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|