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...@googlegroups.com.
I don't understand why you think that "c.Set(i,j, c.At(i,j) + a.At(i,j) * b.At(i,j))" looks much worse than "c[i,j] += a[i,j] * b[i,j]" when comparing a struct representation to your 2-d tables, but you consider "c.Mul(a,b)" compared to "c := a*b" not that bad when discussing the non-goal of supporting mathematical operators. Is it just that multiplying individual elements of a table is a much more common action than multiplying or doing other math on tables? (For the record, I agree that the operators shouldn't be overloaded if this proposal were supported for the reason you gave.)
To me, the limited nature of only supporting 2-d tables makes it seem that an external package optimized for this kind of math is more appropriate than a full-blown language feature. It could be written in C or assembly rather than Go if the Go equivalent is too slow, just like numpy is definitely not written in Python. I personally think that rather than making a language change it would be better for the language overall to investigate why the struct representation is much slower. If some fancy optimizations could be done in gc to, for example, have better analysis to remove bounds checking from more locations it could benefit everyone who uses slices in their every day programming and just make Go that much faster as a whole.
I like Go because it's so simple and so composable that *most of the time* you can solve your problems by just using the tools the language already offers. Adding more tools may help a specific group of people, but I think it's worth investigating to make sure the problem can't be solved with the existing tools and without delving into unsafe. Other than the slight syntax help it doesn't seem to me that this proposal would allow you to do that you can't already do now with an external and specialized library.
(Replying to several messages)
The Rationale section first talks about the matrix support in other
languages. Then, it presents a treatment of them much more limited
than in these other languages, and it is implicitly assumed that this
is enough to make Go as convenient and fast as them. I think that
needs more proof.
There have been a couple of comments implying that the main goal is to
use Go for complex projects where performance is important. I'm
currently working on some projects like this, and the reasons I do not
use Go do not change with the introduction of tables. For some
context: I need to do lots of tensor algebra. Since the dimensions of
these tensors are usually fixed, I can just use arrays.
These programs
are doing calculations for days in many processors, so every bit of
performance is important here. Currently, having to write loops for
matrix operations makes complex algorithms really unreadable (I've
fixed quite a few bugs just translating FORTRAN 77 code with loops to
array operations in Fortran 90). Using functions and methods is also
an option, but tables do not allow me to define a type for a column or
a row of a matrix (the options are to use a slice and make a copy or
use a 2d table, which are far from optimal). Also, although I admit
I've not run benchmarks, I doubt Go can achieve the performance of
Fortran compilers (I think it is naive to be optimist here).
Of course, I would like to have concurrency, the Go standard library, and
the confy development environment that Go provides in these projects,
but only if it doesn't imply a significant loss of readability and
performance.
All this said, scientific computing is a very general term, but the
particular problems each of us try to solve with it are usually very
specific. The fact that tables do not help with my problems does not
mean they cannot help with many others. Obviously, a matrix type will
help to write matrix algebra packages, but it doesn't look to me like
it is going to suppose a big improvement for the users of those
packages.
Its usage in image processing is a valid and strong point,
and I'm sure there will be other interesting ones. But I don't think
this change is going to suppose a significant boost in the adoption of
Go by the scientific community (though I'd like to be wrong), and the
cost is not low.
>> I doubt Go can achieve the performance of
>> Fortran compilers (I think it is naive to be optimist here).
>
> Any reason in favor of skepticism?
I really respect the authors of the Go compilers (it is really amazing
how fast they are improving), but the fact is they are not even
trying. Compilation speed, simplicity and portability are more
important goals for the gc compiler than performance. On the other
hand, Fortran compilers have been developed (also by very competent
people) for decades, trying to make use of every possible trick (no
matter how ugly) just to save a few instructions.
I think Go can be very competitive in scientific computing, but I
don't think performance is going to be its main selling point with the
actual competition.
>> Of course, I would like to have concurrency, the Go standard library, and
>> the confy development environment that Go provides in these projects,
>> but only if it doesn't imply a significant loss of readability and
>> performance.
>
> Tables help improve readability and performance
Again, I'm not comparing Go+tables with Go. I'm just saying that it
will be less readable and performant than in other languages currently
used for scientific programming, which are highly optimised and have
been specifically designed to solve this kind of problems.
>> Its usage in image processing is a valid and strong point,
>> and I'm sure there will be other interesting ones. But I don't think
>> this change is going to suppose a significant boost in the adoption of
>> Go by the scientific community (though I'd like to be wrong), and the
>> cost is not low.
>
> I disagree that it won't be a significant boost (as is probably clear).
I hope you are right, but take into account that we are talking about
a community of which a significant part is still using FORTRAN 77 as
main programming language.
Go is already way more readable than Fortran and C++. Neither of the latter was planned with readability or manteinability in mind (I hope!).
Still, I am with Brendan on the performance. We are of course not going to match fortran the week after this proposal is accepted,
but the compiler in general is getting better by the day. In the long term, I do expect that we match C performance (which seems enough for many
high-performance programs, see NAMD and ORCA, programs for computational chemistry). Even Fortran performance is not impossible.
Other languages in this field had scientific computing as a goal from the beginning (Matlab, R, Julia) or providing sufficient levels of abstraction (operating overloading, for one) that the tools could be provided by libraries (C++, Python).
The opinion that scientists don't care about overloading does not match my experience. Frankly, I only hear from people who don't do any scientific computing.
Finally, your conclusion is very misleading. You say that Go is already interesting for scientific computing because we are discussing it, but it is being discussed because members of that community are requesting languages changes they feel is necessary for Go to be successful.
The opinion that scientists don't care about overloading does not match my experience. Frankly, I only hear from people who don't do any scientific computing. Unless you have some other language to add to the list in my previous post, most of the current languages used for scientific computing support it, which is quite telling. For people with a strong mathematical background, operator overloading improves readability and is a productivity boost.
Like most programmers, scientists want one language/environment to handle all of their programming needs, and so they want a language capable of general purpose tasks, but that is only one part of the requirements they are looking for.
--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/osTLUEmB5Gk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Struct | 2.30 -> 1.1 | 9.12 -> 1.8 |
--
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...@googlegroups.com.
To mention my main complaint with your proposal here in the open:I think any proposal needs an answer to bounds check elision, as that's where the biggest performance penalties lie in the matrix stuff I've done, and I think a lot of others as well. It doesn't have to be range, but that seems like the most appropriate place for it.