Sorry for my late reply.
Thanks Ian for advice on the point "1" of Volker's list (and "fiuu", in
that case go run is so convenient).
I tried benchmark the program (also with the formatting, with larger
matrix) as exercise and everything work well (great performance, beautiful
world that of compiled languages) both for go1.15.8 and go1.16.
*So the answer to the title of this issue is NO *(Volker was right,
obviously, I was wrong with nonsense comparison)*.*
But the difference with the elapsed time still remain and I also noticed
one interesting thing....
package main
import (
"fmt"
"time"
"gonum.org/v1/gonum/mat"
)
func main() {
p := mat.NewDense(3, 3, nil)
a := mat.NewDense(3, 3, []float64{
1, 2, 3, 1, 2, 3, 1, 2, 3,
})
*fmt.Println("") // <-----News here*
start := time.Now()
p.Mul(a, a)
fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))
p.Add(a, a)
fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))
p.MulElem(a, a)
fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))
fmt.Println(time.Since(start))
}
Run "go1.16 build" (with go1.15.8 nothing change) and then run the exe, the
time is changed, completely. I noticed it because the time between the two
version of go was the same when I was printing the matrix "a" and "p"
before starting the operation.
Is there a problem on my use of the time package?
*Thanks a lot to all, I'm surprised for the support that you are giving to
me, great community.*
Il giorno giovedì 25 febbraio 2021 alle 16:11:42 UTC+1 Ian Lance Taylor ha
scritto:
> On Wed, Feb 24, 2021 at 11:46 PM Volker Dobler
> <dr.volke...@gmail.com> wrote:
> >
> > On Wed, 24 Feb 2021 at 20:00, Ian Lance Taylor <ia...@golang.org> wrote:
> >>
> >> On Sat, Feb 20, 2021 at 8:26 AM Volker Dobler
> >> <dr.volke...@gmail.com> wrote:
> >> >
> >> > 1. Do not use go run main.go. Never!
> >>
> >> I want to point out that this is too strong. There are perfectly good
> >> reasons to use "go run main.go". It's a simple convenience operation
> >> that does what it says. If you have a single file Go main package,
> >> "go run main.go" is fine. I do it all the time.
> >
> >
> > I admit that from a technical perspective of an expert
> > this advice is too strong. go run with filename arguments
> > exists for a purpose and of course I too do use go run gen.go
> > regularly and even go run main.go occasionally.
> >
> > But unfortunately "go run main.go" seems to have become
> > a synonym for "run Go code", promoted and parroted on every
> > low barrier introduction blog post about Go resulting in a false
> > impression that "go run main.go" is "the way you execute Go code."
> > Which it is not in general, leading to a lot of confusion on questions
> > like:
> >
> > Why doesn't go run main.go work any longer if I move some of my code to
> a new file server.go?
> > Why doesn't go build main.go foo.go special.go not honour build tags?
> > Why doesn't go test some_test.go run the tests in file some_test.go but
> fails with compiler errors?
> > Why does the trivial program package main; func main(){} lead to memory
> allocations as can be seen by GODEBUG=gctrace=1 go run trivial.go ?
> > Why shouldn't I execute my Go script in my docker container via go run?
> > Why does importing import "./mypkg/mycode.go" throw an error but the
> file ./mypkg/mycode.go does exist and contains the code?
> >
> > [https://github.com/golang/go/issues/43970]
> >
> > I think there is a major problem with "go run main.go": It creates
> > a _false mental model_ of how Go code is built and executed in the
> > minds of _beginners_. Experts know that Go code is not "executed"
> > but compiled, linked and the executable is loaded and executed.
> > Experts know that the Go's main building blocks are packages and
> > that the go tool works best on packages. Experts find it convenient to
> > run a file which is // +build ignore'ed. Experts find go run main.go
> > convenient and will switch to go build the moment it is no longer
> > a single main.go file without thinking about this switch.
> >
> > But newcomers (especially coming from interpreted languages)
> > are not experts and I do believe that exposing them to
> > "go run main.go" does harm building a correct mental model
> > of how Go source code is compiled, linked and executed.
> >
> > Why do people make the errors in the bullet list above?
> > Especially the last 4 points? My hypothesis is that they are too
> > much focused on _files_ than on packages. Why? Maybe because
> > if you are told "Use go run main.go to run your Go code." then
> > this settles the idea that source code files like main.go are the
> > relevant building blocks.
> >
> > Because of that I think you "Never use go run main.go!" is a
> > good advice. It is an advice which is technically wrong.
> > But it helps building the right mental model of how Go works.
> >
> > The advice/rule "You cannot divide by 0!" is a very good advice
> > albeit being technically wrong as there are rings with zero dividers
> > as we experts know. Nevertheless you always tell people to
> > _never_ divide by 0, a blunt lie. But you first have to understand
> > that "you cannot divide by 0" before you can do the expert step and
> > start working on abstract algebra and regularly use zero dividers.
> >
> > In the same sense you have to understand first that the correct
> > way to build Go code is via "go build" (no arguments) which does
> > all the heavy lifting before you become an expert and will happily
> > and safely use go run with filename arguments.
>
>
> That all makes sense, but in cases like this thread we are speaking
> with people new to Go and trying to be helpful. I understand better
> what you are saying when you say "Do not use go run main.go. Never!",
> but it's not a helpful way to begin a reply to a question that has
> nothing to do with "go run". The first response to a question should
> not be "You are doing it wrong!" when in fact this person was not
> doing it wrong. That isn't helpful.
>
> Perhaps you should write a blog post with something like the above
> information, and then you can link to it at the end of a reply, rather
> than as the first thing to say.
>
> Thanks.
>
> Ian
>
--
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/27d6ba3d-6163-4e99-8982-f9500e39748bn%40googlegroups.com.
