Let's add a statistical profiler to Chicken Scheme | Hacker News Reader

Let's add a statistical profiler to Chicken Scheme

more-magic.net

48 pointskryptiskt3 comments

There's been a statistical profiler for Gambit Scheme since 2005 by Guillaume Germain (https://duckduckgo.com/html/?q=guillaume+germain+statprof). It's written in Scheme unlike this one, including the signal handler, which accesses the current continuation of the running program and from that extracts the information it needs. The continuations represent the "real" backtrace as opposed to the tracing, and they are always there of course (there's no disabling them as that would defeat the running of the programs). The profiler could thus extract the proper dynamic context (I don't remember if it does, but it could be extended to do so) and thus avoids the risk for surprise mentioned in the article.

I'd expect most Scheme implementations to have a statistical profiler by now?

Gambit gets several things right (continuation representation, debugger, perhaps multithreading (although other Schemes got that too)), although at the same time its internals are undocumented, difficult to work with (I found the abstractions used a bit lacking, and it's mostly a big amount of code without visible dependency structure which in its current state basically can't be run/changed/analyzed in pieces), and after an unlucky stint at a PhD under its author (1) I stopped plans to work on it. I'm still looking for a Scheme implementation that's got those things down similarly well but is more amendable (perhaps Scheme-48 although it doesn't have any real community).

(1) he's a demanding person to work with, but to be fair mostly the reason for the failure was that I was ill-prepared.

By multithreading, do you mean concurrency, or does Gambit expose raw threads to user programs? I'm rather convinced that a pthreads-like or Java-like interface to threads is too low-level and error-prone for most programming outside of kernel or standard library programming. We have less error-prone concurrency interfaces in Erlang-like CSP or Scala Actors.

I was referring to its built-in raw threads including mutexes, condition variables, and what it calls mailboxes (communication channels between threads) as well as object ports. You can build an Erlang style system easily on top of those (this is Scheme, after all, so you've got macros to help build abstractions, although the system doesn't offer the means to enforce separation (your programs can access symbols that allow to circumvent any separation attempts)), as the Termite project(1) in fact did (also about a decade ago).

(1) https://duckduckgo.com/html/?q=gambit+termite

I was mentioning threads since Marc Feeley, its author, was a forerunner in implementing threads on Scheme systems (he authored the threading SRFI (2)). It's a green threading system (support for millions of threads, it doesn't come with support for libev though, so YMMV).

(2) http://srfi.schemers.org/srfi-18/

Thing is, the thread system, like the rest of the system (e.g. he devised an I/O layer that tries to be OS agnostic), tries to come as shiny closed system for the user (with comprehensive user docs), whereas I'd much prefer for the parts to be openly accessible/exchangable. For example I'm often barely using the built-in OS-agnostic I/O layer and instead wrote interfaces to POSIX via the FFI. And I don't use the threading system often. My biggest use case for multi-threading is SMP support which I need to do by running separate Gambit instances (or by way of fork), accessing a common storage layer implemented via POSIX (currently in the works, and I'm writing it in a way that should make it easy for me to move to other Scheme systems).

In essence, from my point of view it's a system from academia with a quite explicit attempt to be practical for industrial use but falling short on the latter front pretty much exactly because it tries to do the latter itself.

Reply on news.ycombinator.com