Jörg Seebohn

Sorry, but I do not know Go. I've only read about it. My understanding is that Go routines are high speed user threads (aka fibers or coroutines). And if Go...

If written test code to see whether goroutines could be implemented the way we've speculated. See https://github.com/je-so/testcode/blob/master/gochan.c I've implemented only the single thread case and got more than 11000 msg/msec....

Now the test code ([gochan.c](https://github.com/je-so/testcode/blob/master/gochan.c)) supports system threads. It scales very well: gochan: 1_30000 send/recv time in ms: 1 (30000 msg/msec) gochan: 32_30000 send/recv time in ms: 46 (20869 msg/msec)...

There is a much better test driver in directory https://github.com/je-so/testcode/tree/master/iperf which scales linear with the number of scores. Try it with chan if you want.

With padding of the variables to the size of one cache line performance is much better!! See https://github.com/je-so/iqueue/blob/master/README.md for some numbers.

Yes, the new version is faster. I played with it and changed the input of example/doge from "so c" to "so a" and got "Segmentation fault". Changing definition of noun...

Found another problem in doge.c (with older version cause newer version does a segfault): Changing noun into noun : \"lisp\" | \"language\" | /c+c/ | ... does not work on...

I think a good way to speed up the parser is to replace the calls to malloc/free for small objects with a call to an optimized version which allocates memory...

Simple. Export a generic mpc_free function in the interface. The implementation calls the type specific function free_type1, free_type2 according to the type of object which must be stored at (and...

I wondered how fast a simple LL(1) parser could be without building any AST at all. To test it I have written a very simple interpreted parser which tries to...