Concatenative language
Concatenative topics
Concatenative meta
Other languages
Meta
= Data structures = A good choice of data structures is critical. For example, when constructing a sequence in a loop, it is better to push elements onto a vector with %push% and %push-all% than it is to use %suffix% or %append%, since the latter copy the head of the sequence. When taking sequences apart, using slices instead of subsequence operations can yield a performance boost. For example, calling %rest% on a one-million-element array will allocate a new array with 999,999 elements, whereas calling %rest-slice% will allocate a slice which is a very efficient operation. = Static stack effects = The first step when optimizing Factor code is to ensure that it is compiled with the [[Factor/Optimizing compiler]]. A word will be optimized if and only if it has a static stack effect. To check this, [factor{[ my-word ] infer.}] You can define unit tests which assert this is true, [factor{\ my-word must-infer}] = High-level optimizer = To see how the high level optimizer treats a word, you can use the following tool: [factor{USE: compiler.tree.debugger \ foo optimized.}] You will be able to see if generic dispatch has been eliminated, and if generic arithmetic has been converted to machine arithmetic, and which words have been inlined. You can also pass a quotation to %optimized.%: [factor{[ 100 [ ] times ] optimized.}] The high level compiler can be given [[http://docs.factorcode.org/content/article-hints.html|hints]] and [[http://docs.factorcode.org/content/word-inline%2csyntax.html|inline declarations]] which affects the output of the above. Big picture: The optimizing compiler works on single words. Gather code using %inline% into those words. Give the optimizing compiler assistance in figuring out what types things are. It's does well when it knows, but often lacks for information. = Low-level optimizer = To see how the low level optimizer treats a word, [factor{USE: compiler.cfg.debugger \ foo test-optimizer cfgs.}] = Disassembly = To see the final code generated for a word, use the %disassemble% word. Disassembling words is accomplished using %libudis86% on x86, and %gdb% on PowerPC. Note that %udis% needs to be compiled with the %--enable-shared% option: - [[udis|udis Installation]] = Additional advice = - Take a look at the code in the %extra/benchmark/% directory. These programs are extremely optimized, but also written in a high-level style. - Avoid using dynamic variables in tight loops; use locals or the stack instead. - Immutable locals and stack shuffling are equivalent semantically, and compile to the same code; pick whichever one makes for clearer code. - Mutable locals, on the other hand, incur a performance penalty because a heap-allocated container is made to hold the mutable value. - Core language features such as generic words, the %case% combinator, and so on, are highly-optimized, and might be faster than something you'd cook up on your own. For example, %case% with integer keys turns into a jump table, %member?% with a literal sequence becomes a hashed dispatch or a bit array lookup, generic word dispatch scales very well with a large number of methods, and so on. - Don't use low-level words like %fixnum+%, and so on. Given the right set of %inline%ing declarations and %HINTS%, the compiler can eliminate generic arithmetic, and the result will be safer and more readable than if you attempt these transformations by hand. See also %TYPED%, and dangerous %declare%. - On the other hand, [[http://docs.factorcode.org/content/article-sequences-unsafe.html|unsafe sequence operations]] are useful sometimes when accessing sequence elements in tight loops; however, try to express your code using %map%, %reduce%, or something like that instead, since they already use unsafe operations under the hood. - The optimizing and basic compilers have different characteristics. Some abstractions have zero cost in one, but not the other (eg, locals). = Todo = - the math.vectors.simd and specialized-arrays docs have some optimization advice you could fold into this article. also read slava's blog posts, they explain everything. - Page needs discussion of tuple issues: read-only slots, escape analysis, open coding.
Describe this revision:
Save