Live data from Hacker News

Practices for writing high-performance Go

github.com

91–100 of 102 posts

Re: Practices for writing high-performance Go

#91

Earlier quoted context omitted.

The benchmark game puts c, rust, and c++, in that order, roughly on par in performance, with go being about 2-3x slower. No idea if that's accurate. Sampling bias means people who like performance are optimizing the languages used for performance, and people who just like to get something working quit after the first benchmark in go or python is finished. https://benchmarksgame-team.pages.debian.net/benchmarksgame/..…

If you discard regexredux, then Rust is faster than C and C++ at average: see average bar at "How many times slower graph" [1]. regexredux program is outlier in Rust, because replacement of a regex in string is slower in regex crate, because author of regex crate chose to implement safer, but slower algorithm. To fix this, regex crate must be updated or replaced. I spent two weekends on this. [1]: https://benchmarksg…

mandelbrot is outlier in Rust, because… :-)

Re: Practices for writing high-performance Go

#92
post #85
post #60

Earlier quoted context omitted.

I think you're ignoring caching/preprocessing in your analysis.

I am, yeah; but it’s an infinite regress—if these aren’t the specs of the machine that answers your query, then they’re the specs of the machine that does the spec-work to build the cache.

Or the machine that designs the machine that answers your query.

Re: Practices for writing high-performance Go

#93

Earlier quoted context omitted.

My point is that you should file a Github issue if there isn't one.

Why "should"? Nobody owes the writing of issues.

If you depend on an open source project, and can articulate a problem with it that can be fixed, then I do feel you should file an issue to contribute your insight.

Re: Practices for writing high-performance Go

#94
post #58

any thoughts on whether to use values or pointers to large structs? in practice I haven’t seen any major performance overhead when passing values about.

I don't know what's idiomatic in Go, but I would do whatever makes the code easiest to understand (if that could be an issue). Modern compilers are very good at optimising pass-by-value into a pointer, so write first then measure and then optimise where required.

Re: Practices for writing high-performance Go

#95
post #91

Earlier quoted context omitted.

If you discard regexredux, then Rust is faster than C and C++ at average: see average bar at "How many times slower graph" [1]. regexredux program is outlier in Rust, because replacement of a regex in string is slower in regex crate, because author of regex crate chose to implement safer, but slower algorithm. To fix this, regex crate must be updated or replaced. I spent two weekends on this. [1]: https://benchmarksg…

mandelbrot is outlier in Rust, because… :-)

Because hardware acceleration is used in C and C++ versions. I will fix this soon.

Re: Practices for writing high-performance Go

#96

Earlier quoted context omitted.

C++ is unique in that it aims to be feature-rich, while preserving at much as possible the property of if you don't use it, you don't pay for it . It breaks its own rule occasionally -- RTTI, exceptions, [0] standard library machinery with always-on thread safety -- but the C++ folks go to extreme lengths in the name of performance. There's no small irony in the way embedded folks write off C++ as too heavyweight, gi…

> it aims to be feature-rich Visual basic had a Replace() function back in 1998, to replace substrings. C++ now has many amazingly advanced high-level features, but still no built-in way to replace a substring. I don’t think I needed to write my own string replacing function in any other language I used (I’ve been programming for living since 2000). I like C++ and use it a lot. But these seemingly small issues with i…

String operations of C look so much cleaner and complete than those "algorithmic and templating" ones of C++. And C++ can quickly become difficult to read after overloading various operators on classes or after using fancier less-known features. I personally find C++ too complex and confusing. I know Google dictates some reasonable subset of C++ for Fuchia and that is good. Btw also the dependency management is sometimes really pain with C/C++ - then they had to use crazy compilation tools like GN or Basel to get it compile in various environments and platforms... Programming in go/c# allows to quickly focus to get the work done.

Re: Practices for writing high-performance Go

#97
post #96

Earlier quoted context omitted.

> it aims to be feature-rich Visual basic had a Replace() function back in 1998, to replace substrings. C++ now has many amazingly advanced high-level features, but still no built-in way to replace a substring. I don’t think I needed to write my own string replacing function in any other language I used (I’ve been programming for living since 2000). I like C++ and use it a lot. But these seemingly small issues with i…

String operations of C look so much cleaner and complete than those "algorithmic and templating" ones of C++. And C++ can quickly become difficult to read after overloading various operators on classes or after using fancier less-known features. I personally find C++ too complex and confusing. I know Google dictates some reasonable subset of C++ for Fuchia and that is good. Btw also the dependency management is somet…

> so much cleaner and complete than those "algorithmic and templating" ones of C++

That's C++ strings, too: https://docs.microsoft.com/en-us/cpp/atl-mfc-shared/referenc...

Not only they have better API (replace, tokenize, implicit cast to const pointers), these strings are often faster. That particular class is Windows-only, but nothing prevented C++ standard folks to come up with conceptually similar cross-platform stuff. BTW, that CString class predates C++ standard library by many years.

> And C++ can quickly become difficult to read after overloading various operators on classes or after using fancier less-known features.

Yes, and I saw quite a lot of code like that.

But in other cases these features help with readability. I often code math-heavy stuff in C++ processing vectors, matrices, quaternions, complex numbers, etc. The ability to implement custom math operators on these structures IMO helps with readability.

What doesn't help is the ability to abuse them, like C++ iostreams do with `operator Not just operators, it's generally too easy to abuse features of the languages, writing code that's very hard to work with. Unfortunately, not doing that requires lots of experience with the language.

I'm not planning to switch due to the good parts. First-party SIMD intrinsics support. Trivial interop with C and C++ libraries: hard requirements like OS kernel APIs and GPU APIs, industry standards like libpng, or just very nice to have like Eigen. Very small runtime allows to build dynamic libraries, consume them from anywhere, and not worry about binary size or runtime dependencies. Also tools like debuggers and profilers are very good.

But when performance is less critical, I'm more productive using other, higher-level languages.

Re: Practices for writing high-performance Go

#98

Earlier quoted context omitted.

The benchmark game puts c, rust, and c++, in that order, roughly on par in performance, with go being about 2-3x slower. No idea if that's accurate. Sampling bias means people who like performance are optimizing the languages used for performance, and people who just like to get something working quit after the first benchmark in go or python is finished. https://benchmarksgame-team.pages.debian.net/benchmarksgame/..…

If you discard regexredux, then Rust is faster than C and C++ at average: see average bar at "How many times slower graph" [1]. regexredux program is outlier in Rust, because replacement of a regex in string is slower in regex crate, because author of regex crate chose to implement safer, but slower algorithm. To fix this, regex crate must be updated or replaced. I spent two weekends on this. [1]: https://benchmarksg…

> To fix this, regex crate must be updated or replaced.

I somehow doubt pcre2 is being changed to make the tiny toy C programs run better.

> I spent two weekends on this.

So shouldn't we assume the program performance simply reflects all-those-hours you've spent working on it?

Re: Practices for writing high-performance Go

#99
post #98

Earlier quoted context omitted.

If you discard regexredux, then Rust is faster than C and C++ at average: see average bar at "How many times slower graph" [1]. regexredux program is outlier in Rust, because replacement of a regex in string is slower in regex crate, because author of regex crate chose to implement safer, but slower algorithm. To fix this, regex crate must be updated or replaced. I spent two weekends on this. [1]: https://benchmarksg…

> To fix this, regex crate must be updated or replaced. I somehow doubt pcre2 is being changed to make the tiny toy C programs run better. > I spent two weekends on this. So shouldn't we assume the program performance simply reflects all-those-hours you've spent working on it?

Look at the program:

  fn find_replaced_sequence_length(sequence: String) -> usize {
    // Replace the following patterns, one at a time:
    let substs = vec![
        ("tHa[Nt]", ""),
        ("aND|caN|Ha[DS]|WaS", ""),
        ("a[NSt]|BY", ""),
        ("]*>", "|"),
        ("\\|[^|][^|]*\\|", "-"),
    ];
  
    // Perform the replacements in the sequence:
    substs
        .iter()
        .fold(sequence, |s, (re, replacement)| {
            regex(re)
                .replace_all(&s, NoExpand(replacement)).into_owned()
        }).len()
  }

It measures performance of RE engine. I can switch from regex crate to PCRE2, and program performance will match C.

Re: Practices for writing high-performance Go

#100
post #98

Earlier quoted context omitted.

> To fix this, regex crate must be updated or replaced. I somehow doubt pcre2 is being changed to make the tiny toy C programs run better. > I spent two weekends on this. So shouldn't we assume the program performance simply reflects all-those-hours you've spent working on it?

Look at the program: fn find_replaced_sequence_length(sequence: String) -> usize { // Replace the following patterns, one at a time: let substs = vec![ ("tHa[Nt]", " "), ("aND|caN|Ha[DS]|WaS", " "), ("a[NSt]|BY", " "), (" ]*>", "|"), ("\\|[^|][^|]*\\|", "-"), ]; // Perform the replacements in the sequence: substs .iter() .fold(sequence, |s, (re, replacement)| { regex(re) .replace_all(&s, NoExpand(replacement)).into_o…

> I can switch from regex crate to PCRE2, and program performance will match C.

Perhaps it would; those measurements have not been made.

What does that have to do with re-writing libraries to make tiny toy programs run better?

What does that have to do with program performance being a proxy for programmer effort?

Post reply on HN