You are correct about the concurrency, no hard feeling. thank god this was no tech interview! ;)
BTW i just found this http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=csharpcore&lang2=go It looks like .net core seems to be comparable to go (and better in some cases). And it is only preview 2! My general feeling .net core which is not statically linked can hold its ground very well! This was unexpected for .net and unfortunate for go (which will get better with their improvements in GC etc). On Sunday, October 9, 2016 at 1:27:14 PM UTC+3, ohir wrote: > > Dnia 2016-10-09, o godz. 02:06:01 > Sotirios Mantziaris <smant...@gmail.com <javascript:>> napisał(a): > > Excuse me for a bit of 'ad personam' tone, it is not meant to be mean. > > > And i was comparing the concurrency framework > You did not though. > > > with all the bells and whistles > But your code used none. [e.g. custom data passed to .net task] > > Your present microbenchmark code at most compares malloc and printf > implementations (and .net optimizers). In fact it is not even > concurrent: https://blog.golang.org/concurrency-is-not-parallelism. > > In simplest words: concurrency is all about doing usable things in > one task while other one awaits for some (slow) things to happen. > The pseudo-parallelism is just a byproduct. > > If you really want to compare _speed_ of the products of two compilers > you need to compile the same code with both. It is easy. > > But if you really want to compare _speed_ of the products of two compilers > of different PLs you need to implement the same heavy concurrency in both > PL. > This is not that simple goal. Sometimes it even is not achievable (ie. > in comparing java vs. erlang). > > > From what i understand goroutines are not threads either. There is a > > manager that handles which one runs on which thread, just like the > > implementation of .net. > > Unlike .net Task every goroutine is given its own stack from the creation > time. So it is prepared to do some real work just in time it will execute. > > DotNet, by specification, may even use a single task instance: "The number > of Task instances that are created behind the scenes by Invoke is not > necessarily equal to the number of delegates that are provided. The TPL > may > employ various optimizations, especially with large numbers of delegates." > [https://msdn.microsoft.com/en-us/library/dd537609(v=vs.110).aspx] > > If you still want to compare PLs, do reimplement some (heavily concurrent) > real solution avaliable in golang ecosystem in C# (you do know intimately) > Then you might compare both in production. > > -- > Wojciech S. Czarnecki > ^oo^ OHIR-RIPE > -- 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.
