Comparing Pythagorean triples in C++, D, and Rust • Hacker News Board

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

#71

Post by rrobukef » Mon, Dec 31, 2018, 7:40 PM UTC

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.

I share his opinion for scientific software. I think this is because it is building an algorithm versus software. I think the coupling and scope are just too different.

If your loop takes billions of iterations on gigabytes of data before returning the wrong answer, how do you debug? Breakpoints are useless because which iteration introduced the fault? The critical paths are long. Watchpoint start after you pauzed. Reverse debugging is to slow for millions of instructions. If you change the code with the REPL (other post) you invalidate your previous calculations too. Stacktraces are useless because you inline everything, and the callgraph is shallow anyways. Performance profiling needs special tools: you know the hotspot, the debugger tells you where, not why.

My conclusion: A debugger is good for finding bug in data that moves, not for data that changes.

opinion based on: my debug approach changes depending on the error. Prints are always the easiest solution in the scientific parts.

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

#72

Post by saagarjha » Mon, Dec 31, 2018, 7:44 PM UTC

burntsushi wrote: post #67

saagarjha wrote: post #66

Earlier quoted context omitted.

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.

> Why spin up a debugger when I can just printf it?

Xcode launches into a debugger by default, so it's not really an extra step for what I usually do.

> As others have mentioned, how do debuggers fair on optimized builds?

Not well, if you are planning to have variable names and stepping work correctly.

> Most of my time "debugging" is specifically spent on optimized builds looking at performance issues.

Sounds like a job for a profiler?

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

#73

Post by forrestthewoods » Mon, Dec 31, 2018, 7:46 PM UTC

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 very much do not want to necessarily see the raw in-memory details. I want to see a pretty printed view [...] I can read and comprehend.

This isn't an argument in favor of printf over debugging. It's an argument in favor of making debuggers not suck!

Visual Studio has decent watch-window formatters for STL containers. Vectors and Lists are easy. But it also has nice views into unordered_map and unordered_set. Visual Studio has a .natvis file format for adding custom debugger displays for custom datatypes [1].

If you're broken into the debugger and all threads are paused then a good debugger should be able to display your data however you like. Hell, it could have different display options to choose from if you really wanted!

I also find myself regularly relying on printf to debug. But I view this as a failing of the debugger, rather than the superiority of printf.

[1] I think the natvis format kinda sucks and is not sufficiently powerful. But that's a separate issue.

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

#74

Post by pjmlp » Mon, Dec 31, 2018, 7:46 PM UTC

Ar-Curunir wrote: post #56

pjmlp wrote: post #55

Earlier quoted context omitted.

Last time I bothered with calculus was around 1996, so yeah it isn't something that sticks around.

This doesn't have anything to do with analysis-like techniques, and is closer to combinatorial/number-theoretic stuff that programmers are more likely to be familiar with.

Which on my case happened to be on that same year.

The only math stuff I kept updated was denotional semantics and linear algebra, due to compiler and 3D papers that I regularly read, which is anyway not something any of my peers bothers to do.

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

#75

Post by arunc » Mon, Dec 31, 2018, 7:47 PM UTC

For the sake of history, `range` was found/coined by Andrei [1] [2] as a way to overcome the issues with the iterator pattern (in STL). I wish Eric Niebler credited Andrei somewhere, but I couldn't find any.

Honest question: why should I use ranges after all?

As I understand, ranges are the core of idiomatic D and they are not worth it (as per OP)?

AFAIK, ranges (at least in D) are not thread-safe [3]. So what real benefits does it bring?

[1] https://accu.org/content/conf2009/AndreiAlexandrescu_iterato...

[2] http://www.informit.com/articles/printerfriendly/1407357

[3] https://github.com/carun/parallel-read-tester/commit/3e69da4...

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

#76

Post by burntsushi » Mon, Dec 31, 2018, 7:51 PM UTC

saagarjha wrote: post #72

burntsushi wrote: post #67

Earlier quoted context omitted.

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.

> Why spin up a debugger when I can just printf it? Xcode launches into a debugger by default, so it's not really an extra step for what I usually do. > As others have mentioned, how do debuggers fair on optimized builds? Not well, if you are planning to have variable names and stepping work correctly. > Most of my time "debugging" is specifically spent on optimized builds looking at performance issues. Sounds like a…

> Sounds like a job for a profiler?

Sometimes yes. Sometimes no.

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

#77

Post by atilaneves » Mon, Dec 31, 2018, 7:53 PM UTC

arunc wrote: post #75

For the sake of history, `range` was found/coined by Andrei [1] [2] as a way to overcome the issues with the iterator pattern (in STL). I wish Eric Niebler credited Andrei somewhere, but I couldn't find any. Honest question: why should I use ranges after all? As I understand, ranges are the core of idiomatic D and they are not worth it (as per OP)? AFAIK, ranges (at least in D) are not thread-safe [3]. So what real b…

I wrote the blog post and I definitely think ranges are worth using, and said as much in the link. I just don't think they're worth it in this particular case. The code is usually clearer and more reusable with ranges, and if by chance they're bottleneck (unlikely) then rewrite into raw for loops.

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

#78

Post by TheCoelacanth » Mon, Dec 31, 2018, 7:54 PM UTC

prewett wrote: post #52

clappski wrote: post #22

Earlier quoted context omitted.

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.

Is std::endl guaranteed to flush the stream? I’d think you’d be better off with std::cout::flush(), std::flush if you prefer manipulators. It would certainly be clearer, assuming it’s not temporary debug code.

It is. That is the only reason to use it other than '\n'

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

#79

Post by arunc » Mon, Dec 31, 2018, 7:54 PM UTC

atilaneves wrote: post #77

arunc wrote: post #75

For the sake of history, `range` was found/coined by Andrei [1] [2] as a way to overcome the issues with the iterator pattern (in STL). I wish Eric Niebler credited Andrei somewhere, but I couldn't find any. Honest question: why should I use ranges after all? As I understand, ranges are the core of idiomatic D and they are not worth it (as per OP)? AFAIK, ranges (at least in D) are not thread-safe [3]. So what real b…

I wrote the blog post and I definitely think ranges are worth using, and said as much in the link. I just don't think they're worth it in this particular case. The code is usually clearer and more reusable with ranges, and if by chance they're bottleneck (unlikely) then rewrite into raw for loops.

Thanks!

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

#80

Post by burntsushi » Mon, Dec 31, 2018, 7:55 PM UTC

forrestthewoods wrote: post #73

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 very much do not want to necessarily see the raw in-memory details. I want to see a pretty printed view [...] I can read and comprehend. This isn't an argument in favor of printf over debugging. It's an argument in favor of making debuggers not suck! Visual Studio has decent watch-window formatters for STL containers. Vectors and Lists are easy. But it also has nice views into unordered_map and unordered_set. Vis…

I don't use C++ and I don't use Visual Studio. And even if I did, it would be pretty annoying to have to define debugger specific files just to print my data types. In Rust, I just add a fmt::Debug impl and now everyone who uses my code benefits from it, whether in a debugger (by calling that impl) or by print-debugging.

I'm not here to convince anyone to use printf debugging. I don't care about some grand "argument" in favor of it over something else. What I care about are the tools available to me and the most effective way to debug, has historically, for me, been to use printf.

This does not mean I only use printf. This does not mean I hate debuggers. This does not mean that I think debuggers are useless. This does not mean that I think debuggers couldn't or shouldn't be improved. This does not mean that I don't use profilers when debugging performance issues. All it means is that my tool of choice for every day debugging is printf. It is a convenient for me on a number of different dimensions.

That there could exist a theoretically better tool sounds like a great reason for someone to go out and build something. But that someone isn't me, at least not right now.