4 ms·

The point is to sell Swift. In the C++ example, he didn't cast each integer to int64, but he manufactured a reason to do it in Go and Swift. Perhaps this means

by jamra 11y ago

The point is to sell Swift. In the C++ example, he didn't cast each integer to int64, but he manufactured a reason to do it in Go and Swift. Perhaps this means that Swift's compiler optimizes that particular case almost as good as Go's. It doesn't matter much because it's a single threaded useless benchmark. It's the kind of thing that can change with a new Go or Swift release. As you know better than I, Go slowed down a small amount when the recent GC optimizations were done. Is that a reason to use Go less? No. The GC is quite amazing (and there is HTTP2 support). In general, why do I care if there are slight variations in the speed of a for loop? The bottleneck in any app is the database or network access. Maintenance and readability matter to me a lot more than minuscule variations in speed. As someone who programs in Go and Swift, I can tell you that Swift has some things Go doesn't. For one, it has generics. Even still, I would likely never use it over Go on any code that runs on a server. This is due to readability and the Go standard library. I would still choose Swift over Go for iOS development. This is due to how the iOS stack is premised on object inheritance.

masklinn 11y ago
> The point is to sell Swift. In the C++ example, he didn't cast each integer to int64, but he manufactured a reason to do it in Go and Swift. Wow, the crazy is strong with this one. The reason for the cast is that C++ follows C in implicitly converting between integer sizes but neither Swift nor Go do, remove the casts and the code doesn't compile: > swiftc -O test.swift -o test_swift test.swift:8:18: error: cannot convert value of type 'Int' to expected argument type 'Int64' x.append(i); > go build test.go # command-line-arguments ./test.go:12: cannot use i (type int) as type int64 in append And while the correct fix was probably to type the loop variable as an int64 (which incidentally is ugly and non-obvious in Go, you have to convert one of the for loop's bounds to an int64 were Swift will just let you explicitly type the loop variable to Int64) it also changes jack shit to the runtime: > time ./test-go-type 9999010000 ./test-go-type 10.88s user 0.86s system 153% cpu 7.660 total > time ./test-go-cast 9999010000 ./test-go-cast 11.04s user 0.87s system 154% cpu 7.699 total
- jamra 11y ago
  Ignoring the inappropriate ad hominem... Why not type the loop variable as int64 in go? Why not just use an int, which would default to int64 on a 64 bit system? Why not just use sum := 0? Generally benchmarks don't say much unless one of the languages perform extremely poorly. This benchmark doesn't say anything of value.
  - masklinn 11y ago
    > Ignoring the inappropriate ad hominem... Seems appropriate to me, you're trying to spin a shit "benchmark" into some sort of conspiracy theory against your pet language and for your arch-nemesis or something. > Why not type the loop variable as int64 in go? Have you actually read my comment? 1. why not indeed, maybe because it's kind of a pain in the ass to do? 2. and that's got no relevance anyway, it changes pretty much nothing to the runtime > Why not just use an int, which would default to int64 on a 64 bit system? Because leaving that stuff to random half-specified defaults is a terrible idea when you have exact-sized integers you can be certain of. > Why not just use sum := 0? Because if integral numbers don't default to 64 bits or more or arbitrary-size integers, you get signed overflows.

by jamra 11y ago

masklinn 11y ago

> The point is to sell Swift. In the C++ example, he didn't cast each integer to int64, but he manufactured a reason to do it in Go and Swift. Wow, the crazy is strong with this one. The reason for the cast is that C++ follows C in implicitly converting between integer sizes but neither Swift nor Go do, remove the casts and the code doesn't compile: > swiftc -O test.swift -o test_swift test.swift:8:18: error: cannot convert value of type 'Int' to expected argument type 'Int64' x.append(i); > go build test.go # command-line-arguments ./test.go:12: cannot use i (type int) as type int64 in append And while the correct fix was probably to type the loop variable as an int64 (which incidentally is ugly and non-obvious in Go, you have to convert one of the for loop's bounds to an int64 were Swift will just let you explicitly type the loop variable to Int64) it also changes jack shit to the runtime: > time ./test-go-type 9999010000 ./test-go-type 10.88s user 0.86s system 153% cpu 7.660 total > time ./test-go-cast 9999010000 ./test-go-cast 11.04s user 0.87s system 154% cpu 7.699 total

jamra 11y ago
Ignoring the inappropriate ad hominem... Why not type the loop variable as int64 in go? Why not just use an int, which would default to int64 on a 64 bit system? Why not just use sum := 0? Generally benchmarks don't say much unless one of the languages perform extremely poorly. This benchmark doesn't say anything of value.
- masklinn 11y ago
  > Ignoring the inappropriate ad hominem... Seems appropriate to me, you're trying to spin a shit "benchmark" into some sort of conspiracy theory against your pet language and for your arch-nemesis or something. > Why not type the loop variable as int64 in go? Have you actually read my comment? 1. why not indeed, maybe because it's kind of a pain in the ass to do? 2. and that's got no relevance anyway, it changes pretty much nothing to the runtime > Why not just use an int, which would default to int64 on a 64 bit system? Because leaving that stuff to random half-specified defaults is a terrible idea when you have exact-sized integers you can be certain of. > Why not just use sum := 0? Because if integral numbers don't default to 64 bits or more or arbitrary-size integers, you get signed overflows.