On Jan 18, 2021, at 4:39 AM, Kevin Chadwick <m8il1i...@gmail.com> wrote:
> 
> 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?

Go arrays are perfectly usable. My comment had more to do with the fact that
you'd just have a fixed number of threads and if synchronization using channels
is not fast enough, you'd have to roll your own, in which case Go doesn't
really buy you much. I'd just keep the simulator code as a separate process
that does nothing but simulation and have it communicate with a separate
program that does visualization, logging etc. which can be in Go. Pete Wilson
in his response said that simulated cores are already generated functions in C
so this is not a big step. I'd just have the code generator generate the whole
simulator or something like it. Just different tradeoffs to consider.

-- 
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/FF9E41C6-1277-428E-8464-54697359858B%40iitbombay.org.

Reply via email to