5 ms·

I don't know if you've read the benchmark code from The Benchmark Game, but anyone who has looked at the code takes those results with a grain of salt, or disca

I don't know if you've read the benchmark code from The Benchmark Game, but anyone who has looked at the code takes those results with a grain of salt, or discards them entirely. For example, the C/C++ implementations use arena allocators, and they could do the same for the Go implementations, but they don't. The Benchmark Game is a joke. Here it is, for anyone who wants a good laugh: https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

galangalalgol 4y ago
I disagree, but they do take some effort to use effectively. Isaac (or someone) has spent a lot of time segregating out idiomatic simple, and overoptimized solutions. I have looked at the programs, and within the idiomatic programs similar to the types of stuff I do (not a lot of allocation) go varies between 30% and 300% more CPU time. And I have used it as I said. Because go is compiled to native people keep suggesting it is a systems language. Fortran is compiled to native too, but I don't want to write a kernel driver in it. Go has a huge niche, back-end. I think it has plenty of competition there with java and c#, but I reach for go because it makes things quick and easy. I might learn c# if back-end was my day to day, but it isn't. Using c++17 (don't know 20 yet) for very small embedded targets works fine, easy FFI into the BSP, small to no runtime depending on usage. Trying to target that with go would add a lot of extra challenge. I think something like rust or preferably a subset of it for c++ ise cases makes sense. My next project without a GPU I have penciled in rust on the plan. The other developers are excited. Still too hard to use gpu with it. Or rather too immature. The other developers like go too, but throughput will be critical without the gpu, and every little bit will count. And for numeric code it wouldn't just be a little bit of a hit. I wouldn't even suggest julia, and that is as close to a do-it-all language as I have seen.
galangalalgol 4y ago
I looked again at the idiomatic solutions and of the GC languages, on the benchmarks that are relevant to me, go leads the pack (except unchecked swift which doesn't really count, and julia which I think may use actual magic). I feel somewhat vindicated in not bothering to learn c# yet. I am trying to become more fluent at julia though. It already has a very extensive set of libraries from it's community. I may eventually use julia for the things I reach for go for now, and probably some of the things I use matlab, c++ and cuda for.
pclmulqdq 4y ago
As a Go expert, you should consider fixing it, and more people will be willing to use Go for performance-oriented projects. Like it or not, a lot of people go to the benchmarks game website to think about programming language performance.
igouy 4y ago
Compare GC Java with GC Go. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- galangalalgol 4y ago
  Thanks for the work separating out the solutions. It really helps compare the sort of code I'd actually write in those languages. Also, what is the reasoning behind no numpy? I'd never do something like nbody or Mandelbrot without numpy or torch in my actual job, so it isn't idiomatic in a way. Not a complaint, I could always fork it if I cared enough, just curious about the reasoning. I know pypy didn't really want to be involved. Thought it might be like that for numpy?
  - igouy 4y ago
    pidigits and regex-redux explicitly allow use of C libraries.
__d 4y ago
C++ allows you to control your memory allocations. You can use mark and sweep, you can us reference counting, you can use arenas, you can use local stack, you can use shared memory, you can have custom allocators for any object, you can avoid memory allocations altogether, and any combination of these. C is the same. Java can do some of this, if you twist it hard enough. Go cannot. That's ok -- often, even most of the time, you don't care, and then Go is a fine language. But C++ is useful in a much wider set of domains than many people think, because it offers a level of control that many other languages don't. My favourite analogy? Go (etc) is like an Apple product: smooth, and shiny, and tries to be idiot-proof, but you can only do it the Go way. C++ is more Linux: a mess of incompatible, incomplete, infuriating things that let you do absolutely anything you want, if you invest the effort.

galangalalgol 4y ago

I disagree, but they do take some effort to use effectively. Isaac (or someone) has spent a lot of time segregating out idiomatic simple, and overoptimized solutions. I have looked at the programs, and within the idiomatic programs similar to the types of stuff I do (not a lot of allocation) go varies between 30% and 300% more CPU time. And I have used it as I said. Because go is compiled to native people keep suggesting it is a systems language. Fortran is compiled to native too, but I don't want to write a kernel driver in it. Go has a huge niche, back-end. I think it has plenty of competition there with java and c#, but I reach for go because it makes things quick and easy. I might learn c# if back-end was my day to day, but it isn't. Using c++17 (don't know 20 yet) for very small embedded targets works fine, easy FFI into the BSP, small to no runtime depending on usage. Trying to target that with go would add a lot of extra challenge. I think something like rust or preferably a subset of it for c++ ise cases makes sense. My next project without a GPU I have penciled in rust on the plan. The other developers are excited. Still too hard to use gpu with it. Or rather too immature. The other developers like go too, but throughput will be critical without the gpu, and every little bit will count. And for numeric code it wouldn't just be a little bit of a hit. I wouldn't even suggest julia, and that is as close to a do-it-all language as I have seen.

galangalalgol 4y ago

I looked again at the idiomatic solutions and of the GC languages, on the benchmarks that are relevant to me, go leads the pack (except unchecked swift which doesn't really count, and julia which I think may use actual magic). I feel somewhat vindicated in not bothering to learn c# yet. I am trying to become more fluent at julia though. It already has a very extensive set of libraries from it's community. I may eventually use julia for the things I reach for go for now, and probably some of the things I use matlab, c++ and cuda for.

pclmulqdq 4y ago

As a Go expert, you should consider fixing it, and more people will be willing to use Go for performance-oriented projects. Like it or not, a lot of people go to the benchmarks game website to think about programming language performance.

igouy 4y ago

Compare GC Java with GC Go. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

galangalalgol 4y ago
Thanks for the work separating out the solutions. It really helps compare the sort of code I'd actually write in those languages. Also, what is the reasoning behind no numpy? I'd never do something like nbody or Mandelbrot without numpy or torch in my actual job, so it isn't idiomatic in a way. Not a complaint, I could always fork it if I cared enough, just curious about the reasoning. I know pypy didn't really want to be involved. Thought it might be like that for numpy?
- igouy 4y ago
  pidigits and regex-redux explicitly allow use of C libraries.

__d 4y ago

C++ allows you to control your memory allocations. You can use mark and sweep, you can us reference counting, you can use arenas, you can use local stack, you can use shared memory, you can have custom allocators for any object, you can avoid memory allocations altogether, and any combination of these. C is the same. Java can do some of this, if you twist it hard enough. Go cannot. That's ok -- often, even most of the time, you don't care, and then Go is a fine language. But C++ is useful in a much wider set of domains than many people think, because it offers a level of control that many other languages don't. My favourite analogy? Go (etc) is like an Apple product: smooth, and shiny, and tries to be idiot-proof, but you can only do it the Go way. C++ is more Linux: a mess of incompatible, incomplete, infuriating things that let you do absolutely anything you want, if you invest the effort.