Looking at https://git.parallelcoin.io/loki/gists/src/commit/d6cabfd0933d0cda731217c371e0295db331ebb1/tailrecursion-generic.md <https://www.google.com/url?q=https%3A%2F%2Fgit.parallelcoin.io%2Floki%2Fgists%2Fsrc%2Fcommit%2Fd6cabfd0933d0cda731217c371e0295db331ebb1%2Ftailrecursion-generic.md&sa=D&sntz=1&usg=AFQjCNEHisFtMv-4aY06Qb473mdA1_vEpQ>, I am wondering why you put in pseudocode, instead of actual code that can be run? Does this require a language change? If so, you might want to make that clear. If not, then providing runnable code would be helpful.
Also, I wonder about statements like: > If it happens that during compilation the compiler finds that several > parts can be merged, the actual execution that results will likely be > inlined as well. > I think you might be overestimating the go compiler. Have you actually tried this to see what inlining and optimizations actually occur? On Wednesday, April 3, 2019 at 5:45:45 PM UTC-4, Louki Sumirniy wrote: > > I have been doing a lot of work involving essentially declarative > (nominally) complex data types involving several layers of encapsulation. > > I had seen here and there examples of this 'Fluent' method-based pipeline > chaining, with methods passing through receivers to invoke multiple > distinct functions in the type. Here is a gist about it with an example: > > > https://git.parallelcoin.io/loki/gists/src/commit/d6cabfd0933d0cda731217c371e0295db331ebb1/tailrecursion-generic.md > > It occurred to me that if one used this to construct complex graphs of > processing, that the CPU's branch predictor would probably be on fire for > that time, since even though these binary blobs are being possibly > arbitrarily constructed based on random inputs, they will have a > substantial amount off scope in common, so... > > It might then be possible to further amplify this effect by allowing the > runtime to lay the code ahead of the execution a bit like Magneto pulling > those metal blocks up as he walks forwards. > > I don't know how verbose it is, just at first blush, I am generally not > fond of closure syntax in Go, but it seems to me like this dynamic > construction pattern would be very good for speeding up complex processing > with significant variance in sequence. > > For example, playing back a journal into a database - a scouting thread > could pre-process some of the key but simple and salient data about the > segments of the journal, and construct ahead of time cache locality > optimised code and data segmentation that will run with 100% confidence > based on the structure and composition of the data. > > At the moment I am just using it to chain validators together, but, for > example, generating a graph from a blockchain ledger, in order to perform > validation, can have a front-running pass that first generates the > join/split paths of tokens intersecting with accounts. This graph forms the > map of how to process the data, and for parallelisation, such a graph would > allow the replay processing to be split automatically to make optimal use > of cores, caches and memory bus. It could even farm the work out acrosss > the network and all of the cluster nodes process their mostly isolated > segment, then share their database tables directly and voila. > > Such processing is naturally easier to construct using recursion, and with > composition of closures in this way, it should also be quite efficient. > Although at with current go 1.10+ syntax it is a little clumsy, each part > is small and this helps a lot. > > When I am making big changes to code, I have this sensation like I am > walking on unstable ground, because sometimes I can get a way into > something and discover I passed the correct route some way back and I > didn't commit before it and now I have to start all over again. > > Small pieces less than a screenful at a time are very manageable. Just > gotta get a handle on that vertigo :) > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
