Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing Pythagorean triples in C++, D, and Rust

atilanevesoncode.wordpress.com

Post reply on HN
Print view View original

61–70 of 118 posts

Re: Comparing Pythagorean triples in C++, D, and Rust

#61

Post by pjmlp »

clappski wrote: post #22
muizelaar wrote: post #18

The C++ version is taking a compile and runtime short cut by using printf instead of iostream. This pull request has timings with this changed: https://github.com/atilaneves/pythagoras/pull/1#issuecomment...

Using the stuff isn’t really idiomatic - on both modern and legacy code bases I’ve used operator<< overloads on custom types, but never called std::cout in a hot loop or used std::endl to do anything but actually flush the stream.

Sure it is.

Not everyone is micro-optimizing their code just to save a couple of needless extra ms.

I never, ever since 1993, had to work on a C++ project where stdio vs iostream performance made any worthwhile difference, besides stdio being less secure to use.

Re: Comparing Pythagorean triples in C++, D, and Rust

#62

Post by vlovich123 »

atilaneves wrote: post #21

Update: The Rust versions can all be made to run faster with a simple edit. I've updated the timings and edited some of the text.

Not mentioned in the post but I'm assuming you're using O0 for "debug"? It may be worthwhile to reconsider as O0 is now considered to be a tool for compiler authors & regular people should use -Og (or opt-level 1 for Rust) as a way of generating builds that have performance optimizations applied that don't impact debugging.

Re: Comparing Pythagorean triples in C++, D, and Rust

#63

Post by DSMan195276 »

burntsushi wrote: post #32
steveklabnik wrote: post #29

Earlier quoted context omitted.

EDIT: THIS IS ALL WRONG AND BACKWARDS, SEE BELOW -------------------------- > Rust println!() flushes after each call, To be clear, println! does not flush after each call. Many terminals are line-buffered, and so when println! emits a \n, the terminal will flush. So, println! will probably cause a flush , but does not flush itself. println! is the exact same as `print!`, except for the additional printing of \n http…

Are you sure about this? AFAIK, println! uses io::stdout(), which is defined like so: pub struct Stdout { inner: Arc >>>>, } In particular, it's specifically using LineWriter internally, which does flush whenever it sees a `\n`. println! does not itself explicitly flush, but its current implementation does guarantee that it will. However, I don't think this is an API guarantee. In the definition of Stdout, there is t…

> I don't think buffer configuration at the level of the terminal plays a role here.

I just thought I'd confirm that it does not. The 'line buffering' of `tty`s applies to the input to the `tty` (IE. the keyboard) before it goes to the program - basically, the kernel will buffer characters you typed and not send them to the running program until you hit the `eol` character. On the output side the kernel just handles characters as they come in without any buffering/waiting.

Re: Comparing Pythagorean triples in C++, D, and Rust

#64

Post by burntsushi »

saagarjha wrote: post #58
WalterBright wrote: post #48

Earlier quoted context omitted.

I mostly use printf. A debugger is only good for telling you where it seg faulted and the stack trace. The reason is because I write a custom printf to print exactly what I need to know. Debuggers just bury you in irrelevant output.

Debuggers are great interrogating arbitrary program state (it's a printf you don't need to hardcode!) and acting as a REPL for trying out new code.

I'm with Walter on this one. He's right. When I printf-debug, I very much do not want to necessarily see the raw in-memory details. I want to see a pretty printed view. For example, right now I'm working with DFAs, and if I just printed out its transition table as it is in memory, it would be unreadable. Instead, I have a custom fmt::Debug impl that pretty prints something I can read and comprehend.

I don't think I'd say this is the only reason I use printf instead of a debugger, but it's definitely a compelling one.

Re: Comparing Pythagorean triples in C++, D, and Rust

#65

Post by SlowRobotAhead »

yc-kraln wrote: post #57
WalterBright wrote: post #48

Earlier quoted context omitted.

I mostly use printf. A debugger is only good for telling you where it seg faulted and the stack trace. The reason is because I write a custom printf to print exactly what I need to know. Debuggers just bury you in irrelevant output.

A good debugger is good for quite a bit more than that. Watches, break points, performance/profiling. I actually can't believe you're hating on debuggers.

It's funny to me as an embedded programmer seeing people write about how they prefer printf to actual debugging. My printf command can take MANY TIMES longer to run than most of the code that I'm trying to fix.

Maybe it's a software vs hardware thing, but I would end it all if I had to work hardware without breakpoints, watches, and step-through.

Re: Comparing Pythagorean triples in C++, D, and Rust

#66

Post by saagarjha »

burntsushi wrote: post #64
saagarjha wrote: post #58

Earlier quoted context omitted.

Debuggers are great interrogating arbitrary program state (it's a printf you don't need to hardcode!) and acting as a REPL for trying out new code.

I'm with Walter on this one. He's right. When I printf-debug, I very much do not want to necessarily see the raw in-memory details. I want to see a pretty printed view. For example, right now I'm working with DFAs, and if I just printed out its transition table as it is in memory, it would be unreadable. Instead, I have a custom fmt::Debug impl that pretty prints something I can read and comprehend. I don't think I'd…

I mean, why can't you just call that in the debugger when you need it?

Re: Comparing Pythagorean triples in C++, D, and Rust

#67

Post by burntsushi »

saagarjha wrote: post #66
burntsushi wrote: post #64

Earlier quoted context omitted.

I'm with Walter on this one. He's right. When I printf-debug, I very much do not want to necessarily see the raw in-memory details. I want to see a pretty printed view. For example, right now I'm working with DFAs, and if I just printed out its transition table as it is in memory, it would be unreadable. Instead, I have a custom fmt::Debug impl that pretty prints something I can read and comprehend. I don't think I'd…

I mean, why can't you just call that in the debugger when you need it?

Why spin up a debugger when I can just printf it? :-)

As others have mentioned, how do debuggers fair on optimized builds? Most of my time "debugging" is specifically spent on optimized builds looking at performance issues.

Re: Comparing Pythagorean triples in C++, D, and Rust

#68

Post by SlowRobotAhead »

bluejekyll wrote: post #38
the_duke wrote: post #9

Earlier quoted context omitted.

Someone found a single character change providing a 2x speedup: https://www.reddit.com/r/rust/comments/ab7hsi/comparing_pyth...

To quote that reddit post, which I think has some good interesting details about why: “I believe the problem with ..= is that x..(y + 1) is not identical with x..=y. They are nearly equivalent on most values for x and y, except when y == i32::max(). At that point, x..=y should still be able to function, while x..(y + 1) is allowed to do nothing.”

I don't know anything about Rust, but is it part of it's "safety" that it has operators to allow rollover of type max size and others that do not?

As a C programmer, that sort of feels like cheating ;)

Re: Comparing Pythagorean triples in C++, D, and Rust

#69

Post by steveklabnik »

SlowRobotAhead wrote: post #68
bluejekyll wrote: post #38

Earlier quoted context omitted.

To quote that reddit post, which I think has some good interesting details about why: “I believe the problem with ..= is that x..(y + 1) is not identical with x..=y. They are nearly equivalent on most values for x and y, except when y == i32::max(). At that point, x..=y should still be able to function, while x..(y + 1) is allowed to do nothing.”

I don't know anything about Rust, but is it part of it's "safety" that it has operators to allow rollover of type max size and others that do not? As a C programmer, that sort of feels like cheating ;)

Safety means "memory safety". Integer overflow cannot cause memory unsafety directly, and so it's safe.

(safe) Rust does not claim to make your code correct, it claims that it will not have undefined behavior.

We do care about helping you make your code correct; it will check for overflow and panic at runtime in debug builds. But it's a secondary concern. Memory safety is hard enough!

Re: Comparing Pythagorean triples in C++, D, and Rust

#70

Post by burntsushi »

SlowRobotAhead wrote: post #65
yc-kraln wrote: post #57

Earlier quoted context omitted.

A good debugger is good for quite a bit more than that. Watches, break points, performance/profiling. I actually can't believe you're hating on debuggers.

It's funny to me as an embedded programmer seeing people write about how they prefer printf to actual debugging. My printf command can take MANY TIMES longer to run than most of the code that I'm trying to fix. Maybe it's a software vs hardware thing, but I would end it all if I had to work hardware without breakpoints, watches, and step-through.

Why is it funny? And why do you not consider printf to be "actual" debugging? I mean, if printf wasn't available to me or was for some reason otherwise inconvenient, then I would look for other avenues to debug, perhaps by using a debugger! This isn't that mystifying.

As I said above, this is very heavily dependent on preferred workflows and what you're working on. Long ago, I remember doing some robotics work in C, and a debugger was invaluable.

Post reply on HN