Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!newsfeed.fsmpi.rwth-aachen.de!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail From: David Kuehling Newsgroups: comp.lang.forth Subject: Re: Measuring execution speed -- profiling in Forth? Date: Mon, 17 Mar 2014 08:00:24 +0100 Lines: 59 Message-ID: <87d2hls41j.fsf@mosquito.pool> References: <53246658$0$25047$e4fe514c@dreader37.news.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: news.uni-berlin.de LTkeqGNlpA6nf3JM/R5kEAd1O/Ch0tHq96urthMQDt85jr7oc= Cancel-Lock: sha1:TpQjE/RLTKB0Csgd/aBbJWeewNg= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Xref: csiph.com comp.lang.forth:29054 >>>>> "Albert" == Albert van der Horst writes: > In article , > Assad wrote: [..] >> How to measure the execution speed of an algorithm in Forth? >> >> In other languages, I would use a profiler which would break out the >> execution speed taken by various parts of the code, which is quite >> helpful. >> >> How might one do this in Forth? >> >> If I were to build it myself, I would essentially fetch system time >> (in milliseconds) and then have it accumulate the time spent within a >> word into a variable. >> >> Although I believe someone mentioned that GForth has a profiler...? > On Pentiums practical succes can be had with the real time counter, > allowing for nanosecond resolution. You need a single code word in > assembler. This depends on the Forth. The following code from ciforth > can help: Here is code for Gforth on AMD64 (x86-64)-systems that reads the cycle counter. This should work on any 64-bit x86 linux: abi-code tsc@ ( -- u ) rdtsc .d ax -8 di d) mov .d dx -4 di d) mov -8 di d) ax lea \ compute new sp in result reg ret end-code You can then go on and redefine : and ; to add collect execution count and time information for all forth routines defined in your code. You can see a simple profiler based on this concept is here: http://mosquito.dyndns.tv/opensvn/free/branches/brainless-abi/profiler.fs A more portable version without using the x86 cycle-counter is here: http://sourceforge.net/p/forth-brainless/code/HEAD/tree/trunk/profiler.fs It uses Gforth's CPUTIME word instead (less accurate and more overhead). Of course the overhead added to all definitions is very noticeable and collected timing data will therefore not be representative (unless you are more careful to only enable the profiler on definitions that take about an order of magnitude more execution time than the profiling instrumentation code takes). cheers, David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg Fingerprint: B63B 6AF2 4EEB F033 46F7 7F1D 935E 6F08 E457 205F