On 1/17/21 4:46 PM, Bakul Shah wrote: > I’d be tempted to just use C for this. That is, generate C code from a > register > level description of your N simulation cores and run that. That is more or > less > what “cycle based” verilog simulators (used to) do. The code gen can also > split > it M ways to run on M physical cores. You can also generate optimal > synchronization code. > > With linked lists you’re wasting half of the memory bandwidth and potentially > the cache. Your # of elements are not going to change so a linked list doesn’t > buy you anything. An array is ideal from a performance PoV.
Potentially forgive me and ignore this message if inappropriate as I haven't been paying close attention to this thread at all really. However, it strikes me that arrays are perfectly usable in GO. Similarly to how you might use a global array with tinygo to ensure memory usage limits are not breached. What is the issue of using an array in Go? Even a global one, *IF* suited to the task at hand and dishing the work out to workers with a scheme a little more complex than odd, even etc. as required? With the benefit that an off by one etc. causes a panic and not something potentially worse? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9768615d-180e-42fb-9677-da21b5105c37%40gmail.com.
