71–80 of 119 posts
Earlier quoted context omitted.
If there's only one backing type being looked up. If there's more than one, the inline cache thrashs like they're saying.
JRuby has had polymorphic inline caches for like a decade and CRuby will actually cache multiple types in the method cache as long as they cache the same method since https://github.com/ruby/ruby/pull/2583
And still on CRuby if you have any dynacism, you thrash your cache.
Earlier quoted context omitted.
Vague statements without sources are not facts. And even without sources comparing Go to Java and .NET doesn't even make sense in the context.
Since it is so hard for you to use Google, here you go: https://cr.openjdk.java.net/~vlivanov/talks/2017_Vectorizati... https://www.codeproject.com/Articles/1223361/Benchmarking-NE... https://clearlinux.org/blogs-news/performant-containerized-g... Now go play with your facts.
So everybody can see how dishonest pjmlp is towards Go, here is their interpretation of Intel's conclusion:
> Intel has recently published an article on using Go, their advice? Manually use cgo or Go Assembly for the AVX.
.
.
And here is the actual Intel conclusion from the link:
> The examples show how to use Intel AVX-512 with Go to improve application performance using three different methods: direct access with Go assembly, using the Go cgo interface with intrinsics for Intel AVX-512, and via indirect access with 3rd party libraries such as Gonum.
> Each method showed that using Intel AVX-512 improved Go application performance, with shorter execution times and improved date throughput overall. Using Go assembly with direct access to the CPU instruction set was faster than indirect access using cgo or Gonum.
> Clear Linus OS makes it easy to use Intel AVX-512 in Go because Clear Linux OS provides a deeply optimized software stack, including Intel AVX-512 enabled software.
.
.
To say pjmlp's interpretation was uncharitable is an understatement.
Earlier quoted context omitted.
Those optimizations could be taken advantage of via gccgo. Also many other languages keep having backend issues, because those optimizations are too focused on C and C++ code semantics.
> Also many other languages keep having backend issues, because those optimizations are too focused on C and C++ code semantics. Attribute it to LLVM monoculture.
"I do not mind that Go lacks exceptions or generics. These features are often overrated." I agree 100%. I've used them both in C++. I hope Go never gets them.
Exceptions, OTOH, I hope never see the light of day in Go. Curse them.
Go mostly has been only picking up easy wins so far. I haven't seen any attempt to go further than that. Which is fair strategy for first few years since everything comes with a cost. But, people now expect to see more obviously specially the more it's being compared to more sophisticated languages and compilers.
Earlier quoted context omitted.
> But, people now expect to see more obviously [..] I don't. I mean, yay for improvements, but it's already working great for my usecases.
Same here. Go is now my daily driver and main language, and I'm perfectly satisfied with it. Quite the opposite of expecting more, I'm very fearful on what may change or be added in go-2 (which is actually a reason why I'm currently learning C, just in case).
Not Scala though, they went overboard with that one.
Does it really, though? Go really isn't meant for number crunching, or any CPU-bound code, really. I think it's just fine for a language to not strive to emit the fastest possible code. I don't mind having an ecosystem where build times are fast in return for less optimized code. We already have plenty of languages that do the opposite (Rust, C++, Haskell, ...), and I would personally hate to see Go's compilation/lin…
"I do not mind that Go lacks exceptions or generics. These features are often overrated." I agree 100%. I've used them both in C++. I hope Go never gets them.
"I do not mind that Go lacks exceptions or generics. These features are often overrated." I agree 100%. I've used them both in C++. I hope Go never gets them.
Earlier quoted context omitted.
> But, people now expect to see more obviously [..] I don't. I mean, yay for improvements, but it's already working great for my usecases.
What are your usecases, if you don't mind me asking? I am considering replacing our HTTP-heavy processes currently written in C++ with Go. However, after reading this thread I'm not so sure. Compilation time isn't that big of an issue for us, but having a simpler way of doing networking would be a win. I can't tell if that ease of use would be trumped by poor performance.