Rust programs versus Go • Hacker News Board

Re: Rust programs versus Go

#171

Post by simias » Wed, May 16, 2018, 5:43 PM UTC

PopsiclePete wrote: post #167

simias wrote: post #123

Earlier quoted context omitted.

Meh. I might have a huge Stockholm syndrome with manual resource management since I've basically started coding with C and used GC-free languages for most of my life since them but I never really understood why people liked GCs so much outside of scripting languages where convenience trumps correctness and you just litter your resources around instead of tracking them properly. Are people using GC languages really of…

I'm guessing you've never written heavily concurrent code. C/C++/Rust are totally fine when you have a single thread. It's concurrency and parallelism where object ownership and who gets to destroy what and when becomes a real problem unless you have GC.

> I'm guessing you've never written heavily concurrent code.

Guess again.

> C/C++/Rust are totally fine when you have a single thread. It's concurrency and parallelism where object ownership and who gets to destroy what and when becomes a real problem unless you have GC.

Given that one of Rust's main shticks is concurrency and parallelism it's an odd thing to say. You can always use an Arc if you want reference counting between threads which is sort-of GC but opt-in and perfectly deterministic.

Re: Rust programs versus Go

#172

Post by _ek94 » Wed, May 16, 2018, 5:57 PM UTC

jerf wrote: post #97

weavie wrote: post #13

Earlier quoted context omitted.

Go seems to perform really poorly in the regex-redux. Against both Node and Python Go is way faster (as one would expect) apart from with the regex-redux.. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Does Go just suck with it's regex performance? Would this be easy to fix by just pulling in a C regex library?

I disagree with the people saying the benchmarks game is useless. It mostly seems to conform to my own experiences with the various languages involved. The exception is the regex benchmark, which has little to do with the languages and everything to do with the regex library used by the language. If the dynamic scripting languages were required to use regex engines implemented in pure Python/Perl/PHP/JS, their perfor…

> Go's standard library provides a regex library that provides certain O() guarantees, but has a significantly larger constant factor than PCRE-like regexs.

While that is true, Rust's regex library makes the same guarantees.

I'd also like to push back on the idea that perf comparisons are meaningless if one implementation has degenerate cases. Pathological behavior in a backtracking engine happens very rarely, and backtrackers typically come with features that are not supplied by O(n) engines. Someone in the PCRE camp might complain that the benchmark isn't fair because go's engine can't handle backreferences. The different approaches come with different features (backreferences vs garenteed O(n) running time), but they do have a place where their problem domains overlap. It is not useless to examine how they perform in that area.

Re: Rust programs versus Go

#173

Post by steveklabnik » Wed, May 16, 2018, 6:08 PM UTC

Const-me wrote: post #169

steveklabnik wrote: post #164

Earlier quoted context omitted.

> If you think something that hasn’t changed in 16 years is unstable, I’d like to hear your definition of stability. That's not what I'm saying, to be clear. What I'm saying is this: > I don’t think the fact that ISO has standardized some parts of the language but not other is hugely important. This is very true for C and C++, but less true for Rust. This means that, depending on how you define the rules, certain thi…

> This is very true for C and C++, but less true for Rust Right, Rust has essentially a single implementation, and its standard is written by the developers of that implementation. C++ standard is set by huge international standard-setting body with headquarters in Switzerland. That’s why authors of Rust specs are doing much better job keeping the spec in sync with the actual language and its libraries. IMO this diff…

Agreed 100%.

Re: Rust programs versus Go

#174

Post by jerf » Wed, May 16, 2018, 6:14 PM UTC

_ek94 wrote: post #172

jerf wrote: post #97

Earlier quoted context omitted.

I disagree with the people saying the benchmarks game is useless. It mostly seems to conform to my own experiences with the various languages involved. The exception is the regex benchmark, which has little to do with the languages and everything to do with the regex library used by the language. If the dynamic scripting languages were required to use regex engines implemented in pure Python/Perl/PHP/JS, their perfor…

> Go's standard library provides a regex library that provides certain O() guarantees, but has a significantly larger constant factor than PCRE-like regexs. While that is true, Rust's regex library makes the same guarantees. I'd also like to push back on the idea that perf comparisons are meaningless if one implementation has degenerate cases. Pathological behavior in a backtracking engine happens very rarely, and ba…

"I'd also like to push back on the idea that perf comparisons are meaningless if one implementation has degenerate cases."

That's not what I said. I said, you can't use "X times faster" comparisons if the O() of the two algorithms in question are not more-or-less the same. That does not prevent you from still characterizing performance differences. You just can't do it via "X times faster" statements, because those are only well-defined for things separated by linear factors, and practically defined for things separated by practically linear factors. f(x) = x^2 is not "2 times bigger" than g(x) = x, or any number of "times bigger", whereas h(x) = 3x + 5 can be reasonably said to be "3 times bigger" than i(x) = x + 50, even though it is not the case that h(x) = 3i(x).

Re: Rust programs versus Go

#175

Post by Const-me » Wed, May 16, 2018, 6:51 PM UTC

steveklabnik wrote: post #173

Const-me wrote: post #169

Earlier quoted context omitted.

> This is very true for C and C++, but less true for Rust Right, Rust has essentially a single implementation, and its standard is written by the developers of that implementation. C++ standard is set by huge international standard-setting body with headquarters in Switzerland. That’s why authors of Rust specs are doing much better job keeping the spec in sync with the actual language and its libraries. IMO this diff…

Agreed 100%.

By the way, if you’re going to add SIMD intrinsics into the Rust standard, I think you better contact Intel and ask them whether they OK that.

Or seek legal advice.

According to google patents, Intel has 4537 patents related to SIMD. The reason why GCC is OK with their intrinsics, in 2002 they were put there by Intel employees. Intel obviously wants people to use them because this helps Intel sell their CPUs. But having them standardized can potentially decrease Intel’s profits by undermining these patents and enabling hardware and software emulators.

Re: Rust programs versus Go

#176

Post by steveklabnik » Wed, May 16, 2018, 7:05 PM UTC

Const-me wrote: post #175

steveklabnik wrote: post #173

Earlier quoted context omitted.

Agreed 100%.

By the way, if you’re going to add SIMD intrinsics into the Rust standard, I think you better contact Intel and ask them whether they OK that. Or seek legal advice. According to google patents, Intel has 4537 patents related to SIMD. The reason why GCC is OK with their intrinsics, in 2002 they were put there by Intel employees. Intel obviously wants people to use them because this helps Intel sell their CPUs. But hav…

Thanks! I am not a lawyer, nor was I directly involved in this, but I'll pass it up the tree.

Re: Rust programs versus Go

#177

Post by Const-me » Wed, May 16, 2018, 7:26 PM UTC

steveklabnik wrote: post #176

Const-me wrote: post #175

Earlier quoted context omitted.

By the way, if you’re going to add SIMD intrinsics into the Rust standard, I think you better contact Intel and ask them whether they OK that. Or seek legal advice. According to google patents, Intel has 4537 patents related to SIMD. The reason why GCC is OK with their intrinsics, in 2002 they were put there by Intel employees. Intel obviously wants people to use them because this helps Intel sell their CPUs. But hav…

Thanks! I am not a lawyer, nor was I directly involved in this, but I'll pass it up the tree.

I’m not a lawyer either, I’m a software developer; but I’ve been doing this long enough to develop certain degree of paranoia regarding patents and IP rights legal BS.

Re: Rust programs versus Go

#178

Post by steveklabnik » Wed, May 16, 2018, 7:33 PM UTC

Const-me wrote: post #177

steveklabnik wrote: post #176

Earlier quoted context omitted.

Thanks! I am not a lawyer, nor was I directly involved in this, but I'll pass it up the tree.

I’m not a lawyer either, I’m a software developer; but I’ve been doing this long enough to develop certain degree of paranoia regarding patents and IP rights legal BS.

I hear you! Basically same here. I had not come across this one...

Re: Rust programs versus Go

#179

Post by glangdale » Thu, May 17, 2018, 12:31 AM UTC

jcranmer wrote: post #121

rwj wrote: post #108

Earlier quoted context omitted.

I always find this argument really strange. How is making a complicated decision (which language is best for this task) easier using less information (the benchmarks are only one facet of the decision)?

The name of the website used to be the language shootout; it was subsequently changed to be called the benchmarks game to emphasize that its not a rigorous comparison between languages. Benchmarking is hard. You have to identify workloads that are realistic and representative, large enough to be sure you're hitting the steady-state performance yet small enough you can run them on a regular basis. And, of course, you…

+1 for Duff's device. It's really not good now (as compared to the unrolled loop plus a peel) approach, as all those in-edges to a loop all through the body paralyze the compiler's ability to make good choices.

An anecdote I often share is that we had a hotshit performance programmer who often enclosed his simple C versions of the code with:

#ifdef I_DONT_CARE_ABOUT_PERFORMANCE

The punchline was defining this macro and getting the C version usually improved performance over the giant festival of overly-Pentium-4-focused inline asm.

Re: Rust programs versus Go

#180

Post by burntsushi » Thu, May 17, 2018, 1:24 AM UTC

steveklabnik wrote: post #178

Const-me wrote: post #177

Earlier quoted context omitted.

I’m not a lawyer either, I’m a software developer; but I’ve been doing this long enough to develop certain degree of paranoia regarding patents and IP rights legal BS.

I hear you! Basically same here. I had not come across this one...

I haven't either. FWIW, myself and one of your cohorts at Mozilla had a phone call with Intel (a while ago at this point), and while there were no lawyers on the line, the engineers we talked to sounded very happy about what we were doing.