Travis, glad to hear that you are exploring Harshad Numbers. It is an area where I have done more than a decade of work and I did not know that anyone else even cared about them. If you ever want to know how many thousand digit (or whatever) base 10 (or whatever) numbers have the Harshad property, and of those, how many of their digits are 3 or 11 (or whatever), let me know. I have a Go-language program that uses channels that can answer the question. ;-)
Michael On Thu, Oct 3, 2019 at 12:45 PM burak serdar <bser...@computer.org> wrote: > On Thu, Oct 3, 2019 at 11:59 AM JuciÊ Andrade <oju...@gmail.com> wrote: > > > > Burak, feel free to correct me if I am wrong, but now I think I > understood the heart of the matter: > > > > Your approach to software development is different from mine. Nothing > wrong with that. > > > > . you normally write sequential code, and uses concurrent code where it > fits best. That is fine. > > . I use to write concurrent code, and use sequential code where it fits > best. That is fine as well. > > > > Concurrency mechanisms in Go are so easy to use that it allows me to > take that approach. > > With a little bit of caution to not create a big ball of mud[1], you can > write clean concurrent code. > > You said there is a synchronization overhead when a program uses > channels. That is true. > > On the other hand, when we divide the load among several cores we end up > with a net gain. > > Depending on the task at hand the difference can be staggering! I mean > 15x faster or more! > > > > If we consider that nearly all CPU is multicore these days [2], we will > soon conclude that writing concurrent code even for simple tasks makes > sense, in order to leverage that processing power. > > > > Your concurrent code will run keep running well in newer CPUs. Your > single threaded code won't. > > Not all programs benefit from concurrency. Writing concurrent code for > essentially sequential programs will not benefit from multiple cores, > like generating prime numbers. Do not forget that concurrency includes > overhead for context switch and memory barriers. Using channels in a > sequential program is I think misuse of channels. There is no > performance gain in having a sequence of goroutines, each waiting for > the previous one the complete. > > > > > > Again, nothing wrong with your approach, ok? To each its own. > > > > [1] http://laputan.org/mud/ > > [2] https://www.amd.com/en/products/cpu/amd-epyc-7742 > > > > > > > > > > -- > > 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/41a107de-e426-456a-abab-d0b058e39373%40googlegroups.com > . > > -- > 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/CAMV2RqqGSQd61EE_UfdMYKYAWbZ1mXK8mTPDLv18igE%2BA2R0OQ%40mail.gmail.com > . > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- 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/CALoEmQxhWppWEJ4EjdzNEZE2MH7pvuE2573LLn2X3i-0wFGH%2BQ%40mail.gmail.com.
