Of course, once you post about a problem, you immediately figure it out.
I forgot to update the go files in the package folder to reflect the name
change
package liverserver--> package gols fixes the issue.
On Sunday, January 17, 2021 at 10:14:36 PM UTC-6 DrGo wrote:
> Wondering if someone kno
Wondering if someone knows what is going on here:
I renamed a module in go.mod from liverserver [sic] to gols and imported it
in main.go in a "cmd" subdir. Now I am getting this error when I compile
main.go:
./main.go:8:2: imported and not used: "github.com/drgo/gols" as liverserver
./main.go:
Yes, that is possible.
The simulated cores are already generated functions in C.
It’s my experience that if you can leverage an existing concurrency framework
then life is better for everyone; go’s is fairly robust, so this is an
experiment to see how close I can get. A real simulation system has
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 gener
I’d observed that, experimentally, but I don’t think it’s guaranteed behaviour
:-(
> On Jan 17, 2021, at 10:07 AM, Robert Engels wrote:
>
> If you use GOMAXPROCS as a subset of physical cores and have the same number
> of routines you can busy wait in a similar fashion.
>
WARNING / LEGAL
This particular problem is akin to the way GPUs work; in GPU computing, you
generally marshal all your inputs into one buffer and have the outputs from a
single kernel written to an output buffer (obviously there can be more on
either side). The execution overhead of a single invocation is larg
If you use GOMAXPROCS as a subset of physical cores and have the same number of
routines you can busy wait in a similar fashion.
> On Jan 17, 2021, at 9:50 AM, Pete Wilson wrote:
>
> That’s exactly the plan.
>
> The idea is to simulate perhaps the workload of a complete chiplet. That
> mig
That’s exactly the plan.
The idea is to simulate perhaps the workload of a complete chiplet. That might
be (assuming no SIMD in the processors to keep the example light) 2K cores.
Each worklet is perhaps 25-50 nsec (worklet = work done for one core) for each
simulated core
The simplest mechan
If there is very little work to be done - then you have N “threads” do M
partitioned work. If M is 10x N you’ve decimated the synchronization cost.
> On Jan 17, 2021, at 9:11 AM, Pete Wilson wrote:
>
> The problem is that N or so channel communications twice per simulated clock
> seems to ta
The problem is that N or so channel communications twice per simulated clock
seems to take much longer than the time spent doing useful work.
go isn’t designed for this sort of work, so it’s not a complaint to note it’s
not as good as I’d like it to be. But the other problem is that processors
Thanks for the clarification. The goal was to understand the embedding
better.
I have another question.
Consider the case where example.com/m1/nested is not a separate module.
Due to the rule of "Patterns must not contain ‘.’ or ‘..’ path elements",
the nested package can not embed, as an examp
11 matches
Mail list logo
