On Sun, 12 Nov 2017 17:32:34 +0000 Jesper Louis Andersen <jesper.louis.ander...@gmail.com> wrote: > > extensive CF/DF analysis is probably out of bounds. > > My personal solution would be: > > 1. Get a machine with MASSIVE amounts of memory (initial bet: 128Gig and up) > 2. CodeGen to the MLton compiler (mlton.org) > 3. Do a whole-program compilation. This might take several coffee breaks. > 4. Enjoy the fastest simulator ever.
Perhaps but it may be easier to just use a driver based approach. Compared to tailcalls, the speed difference may be at most a factor of 2. You can always run multiple instances on multiple nodes. Actully for *generated* code I would just use C and tweak the code generator to generate efficient C. Or atleast implement performance critical parts in C. > However, for development you probably want something like SML/NJ because > your lead time could be measured in hours. > > Another path is to cheat in the simulator. Replace circuitry with > hand-coded blocks (i.e., VLSI blocks) which doesn't simulate as much as > they run. I remember we did this at university some 15 years ago in order > to simulate circuits, because they would otherwise be too slow (mind you, > 2000 hardware). Each has its benefits and costs. In late 1990s I implemented a coroutine based simulation library in C++ for something similar. On top of it I built a simulator for a network processor ASIC (& IO cars, internal fabric etc. for a full network switch simulator). This was on a machine with 64MB! -- 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.
