status update 1 (Re: assembler speed...)
in [ASM]
|
Prev: x86 instruction set usage-difference between windows 95 and windows xp ?
Next: peter-bochs-debugger is a GUI debugger for bochs
From: Waldek Hebisch on 30 Mar 2010 17:17 In comp.lang.misc BGB / cr88192 <cr88192(a)hotmail.com> wrote: > > "Waldek Hebisch" <hebisch(a)math.uni.wroc.pl> wrote in message > news:hor3rb$jv2$1(a)z-news.wcss.wroc.pl... > > In comp.lang.misc BGB / cr88192 <cr88192(a)hotmail.com> wrote: > >> > >> well, a status update: > >> 1.94 MB/s is the speed which can be gained with "normal" operation > >> (textual > >> interface, preprocessor, jump optimization, ...); > >> 5.28 MB/s can be gained via "fast" mode, which bypasses the preprocessor > >> and > >> forces single-pass assembly. > >> > >> > >> 10MB/s (analogue) can be gained by using a direct binary interface (newly > >> added). > >> in the case of this mode, most of the profile time goes into a few > >> predicate > >> functions, and also the function for emitting opcode bytes. somehow, I > >> don't > >> think it is likely to be getting that much faster. > >> > >> stated another way: 643073 opcodes/second, or about 1.56us/op. > >> calculating from CPU speed, this is around 3604 clock cycles / opcode > >> (CPU = > >> 2.31 GHz). > >> > > > > For a litte comparison: Poplog needs 0.24s to compile about > > 20000 lines of high-level code generating about 2.4 MB of > > image. Only part of generated image is instructions, rest > > is data and relocation info. Conservative estimate is about > > 10 machine instructions per high-level line, which gives > > about 200000 instructions, that is about 800000 istructions > > per second. > > > > ok. > > > > Poplog generates machine code from binary intermediate form > > (slightly higher level than assembler, typically one > > intermediate operation generates 1-3 machine instructions). > > Code is generated in multiple passes, at least two, in next > > to last pass code generator computes size of code, then > > buffer of appropriate size is allocated and in final pass > > code is emmited to the buffer. > > > > Code generator can not generate arbitrary x86 instructions, > > just the ones needed to express intermediate operations. > > Bytes are emmited via function calls, opcodes and modes > > are symbolic constants (textual in source, but integers > > in compiled form). > > > > granted, direct byte-for-byte output is much faster than what I am doing, > > > > My feeling is that trying to use strings as intermediate form > > (or even "character based dispatch") would significantly > > slow down code generator and the whole compiler. > > > > it depends a lot though as to how much of the overall time would actually go > into this. > text is a lot more expensive in cases where little else is going on, but is > a bit cheaper in cases where there is a large amount of logic code in the > mix. > > in the case of an assembler though, the amount of internal logic is > comparatively smaller, and so string-processing tasks are overall more > expensive... > > > but, the bigger question here is not which is faster, but rather which > offers a better set of tradeoffs. > > direct binary APIs tend to be far less generic than an assembler, for > example, they will be specialized to a particular code generator, ... and so > not as useful for general-purpose tasks (say, multiple code generators using > the same assembler, some input coming from files, ...). > Poplog has code generators for x86 (32 and 64 bit), Alpha (64 bit), M68000, Mips, Sparc, PPC, HPPA (last 4 are 32-bit). Front ends for Pop11 ("native" language of Poplog), Lisp, SML, Prolog. In principle intermediate representation should work for Pascal (granted, a bit unusual due to garbage collection). C would pose problems, some because of pointer artihmetic, bigger one because casts between pointers and integers would interact badly with garbage collector. Still, I would say that Poplog interface is very generic. Of course, binary interface is not so great if you want to create real assembler (or support inline assembly). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl
From: cr88192 on 1 Apr 2010 11:40 "Waldek Hebisch" <hebisch(a)math.uni.wroc.pl> wrote in message news:hotppt$qro$1(a)z-news.wcss.wroc.pl... > In comp.lang.misc BGB / cr88192 <cr88192(a)hotmail.com> wrote: >> <snip> >> >> but, the bigger question here is not which is faster, but rather which >> offers a better set of tradeoffs. >> >> direct binary APIs tend to be far less generic than an assembler, for >> example, they will be specialized to a particular code generator, ... and >> so >> not as useful for general-purpose tasks (say, multiple code generators >> using >> the same assembler, some input coming from files, ...). >> > > Poplog has code generators for x86 (32 and 64 bit), Alpha (64 bit), > M68000, Mips, Sparc, PPC, HPPA (last 4 are 32-bit). Front ends > for Pop11 ("native" language of Poplog), Lisp, SML, Prolog. In > principle intermediate representation should work for Pascal > (granted, a bit unusual due to garbage collection). C would > pose problems, some because of pointer artihmetic, bigger > one because casts between pointers and integers would interact badly > with garbage collector. Still, I would say that Poplog interface is > very generic. > yeah. my assembler is a generic assembler, and so can more or less handle any sort of ASM one wants to generate, which includes nearly the entire x86 ISA (excluding of course some older and system instructions which are unlikely to be needed, and most of AVX, though mostly because there aren't really many processors around which support AVX as of yet...). I don't support other ISA's (such as PPC or ARM), mostly because I don't have any systems which support them (and I am not going to bother to target an emulator). adapting my assembler to PPC wouldn't likely be difficult (new ISA listings, different opcode-encoding rules, ...). adapting my compiler to PPC would be a little more work, but not as much since a lot of generalization already took place when adapting it to x86-64. ARM is likely to be similar to the PPC case. > Of course, binary interface is not so great if you want to > create real assembler (or support inline assembly). > the newer binary API for my assembler can also handle textual ASM fragments as well, although one has to compose them fully beforehand (no printf-style interface...). however, at the moment I am less likely to use it as it is less convinient, and also because my codegens still don't produce large volumes of ASM... or such...
From: wolfgang kern on 1 Apr 2010 14:47 "cr88192" wrote [about..] I followed this thread with interest... and I can only add: never have 'programmers convienience' above any final clients demands !!! Sure, fast(cheap) programming may serve a custumer well, but on the daily usage of it he may you curse more often than I curse Bill the Greedy every day. So I actually wont care the time to assemble a piece of code as long the end-user get what he expect in terms of reliabilty and performance. [C-\+users and friends may see this different]. __ wolfgang
From: cr88192 on 1 Apr 2010 15:29 "wolfgang kern" <nowhere(a)never.at> wrote in message news:hp2prm$ki5$1(a)newsreader2.utanet.at... > > "cr88192" wrote > > [about..] > I followed this thread with interest... > and I can only add: > > never have 'programmers convienience' above > any final clients demands !!! > > Sure, fast(cheap) programming may serve a custumer well, > but on the daily usage of it he may you curse more often > than I curse Bill the Greedy every day. > > So I actually wont care the time to assemble a piece of code > as long the end-user get what he expect in terms of reliabilty > and performance. [C-\+users and friends may see this different]. > well, the simple answer for this one is for people not to write apps in Python... Python is convinient for some developers, but many of the apps I have had the most frustration with have been Python apps (poor performance, randomly failing due to runtime errors, ...). my assembler, OTOH, is fast enough not to bog down my stuff, and for my uses this is probably good enough. simplicity and flexibility is sometimes better than raw performance. for example, consider how many people write apps in languages such as Java and C#, which due to the combination of language design and coding practices almost invariably run slower than would be otherwise possible, but in many of these cases the performance overhead can be justified due to the improved maintainability of using these features. the other extreme is unmaintainable code which may run a slight bit faster, but this is not necessarily a good tradeoff... or such...
From: wolfgang kern on 6 Apr 2010 15:37
"cr88192" <iad: >> I wrote >> [about..] >> I followed this thread with interest... >> and I can only add: >> never have 'programmers convienience' above >> any final clients demands !!! >> Sure, fast(cheap) programming may serve a custumer well, >> but on the daily usage of it he may you curse more often >> than I curse Bill the Greedy every day. >> So I actually wont care the time to assemble a piece of code >> as long the end-user get what he expect in terms of reliabilty >> and performance. [C-\+users and friends may see this different]. > well, the simple answer for this one is for people not to write apps in > Python... > Python is convinient for some developers, but many of the apps I have had > the most frustration with have been Python apps (poor performance, > randomly failing due to runtime errors, ...). obviously true :) > my assembler, OTOH, is fast enough not to bog down my stuff, and for my > uses this is probably good enough. > simplicity and flexibility is sometimes better than raw performance. > for example, consider how many people write apps in languages such as Java > and C#, which due to the combination of language design and coding ? There is actually a very huge gap between 'working code' (which is usually heavyly bloated) against the true machine-relevant oriented way of using hardware. > practices almost invariably run slower than would be otherwise possible, > but in many of these cases the performance overhead can be justified due > to the improved maintainability of using these features. The term 'maintainabilty' (in my point of view) just contains a foreseen bug-recovery or anything to change because not known during the programming phase. I stricly avoid such situatuons by accepting the final users demand as a given task... > the other extreme is unmaintainable code which may run a slight bit > faster, > but this is not necessarily a good tradeoff... [OR SUCH..] Maintainability of any code is just a matter of documentation/comments, but my long term experience with sold software told me, that a working program wont, never ever need any service nor upgrade or "maintain". btw: never act like M$ and sell BUGS as if they where security issues. __ wolfgang |