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

101–110 of 118 posts

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

#101

Post by ZirconiumX »

vlovich123 wrote: post #62
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.

I've usually found -Og to inline functions or optimise out variables I needed to investigate. It's happened often enough that I just use printf in release mode.

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

#103

Post by Shorel »

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.

A debugger is most useful when you don't know what the program does, or how it does what it does. It is amazing for learning a new codebase.

But for actually debugging, a log file is better.

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

#104

Post by barrkel »

WalterBright wrote: post #88
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.

> Watches printf > breakpoints if (condition) assert(0); then I use the debugger to tell me how it got there. > performance/profiling I use a separate tool for profiling: https://dlang.org/dmd-windows.html#switch-profile It's built in to the DMC++ and DMD compilers. Sometimes I mess up the code a bit filling it up with debug code, but when I finally fix it it's git to the rescue. I can be old fashioned when it comes…

I like debuggers for things like examining variables from higher stack frames after a highly conditional break (where printf from every higher stack frame would be lost in noise), for stepping through abstractions (especially in C++, where there may be surprisingly amounts of hidden code executed in overloaded bits and pieces), and for hardware breakpoints (an approach for solving reproducible memory corruption: combine a deterministic memory allocator with memory breakpoints + counters).

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

#105

Post by barrkel »

ufmace wrote: post #94
Jach wrote: post #91

Earlier quoted context omitted.

Maybe you need to try out more powerful dynamic languages? I mean even Python has 'pdb' which gives you a fairly authentic gdb experience, and you can always dir() and help() something in the REPL. For me I find myself not missing a debugger very much at all in Python code, whereas Java code of a certain size and legacy history forces me out of my preferred vim world and into Eclipse for the interactive debugging alo…

Yeah I meant Ruby and Python for dynamic languages, and by debugger I mean the command-line Ruby byebug and Python pdb. Those plus logging/print statements have been all I've needed so far, never felt a need for a GUI debugger, but then I already live in Vim and Tmux. Never tried a command-line debugger for Node/JS, but the Chrome GUI debugger works well enough.

Pry is the way to go for debugging in Ruby. Drop into an interactive REPL with local variable context in situ with binding.pry or binding.pry_remote if in a forked server environment.

For subtle edits of a big chunk of code, my preferred approach is to set everything up in a test case, then pop into the implementation that needs to be changed where all the state is available with a binding.pry, and iterate expressions in the REPL until it's good, then copy my history out into an editor.

In Emacs it's nice and easy with rspec-mode and inf-ruby - run the test from within Emacs and get in-editor REPL once you hit the binding.pry.

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

#106

Post by SeanBoocock »

barrkel wrote: post #104
WalterBright wrote: post #88

Earlier quoted context omitted.

> Watches printf > breakpoints if (condition) assert(0); then I use the debugger to tell me how it got there. > performance/profiling I use a separate tool for profiling: https://dlang.org/dmd-windows.html#switch-profile It's built in to the DMC++ and DMD compilers. Sometimes I mess up the code a bit filling it up with debug code, but when I finally fix it it's git to the rescue. I can be old fashioned when it comes…

I like debuggers for things like examining variables from higher stack frames after a highly conditional break (where printf from every higher stack frame would be lost in noise), for stepping through abstractions (especially in C++, where there may be surprisingly amounts of hidden code executed in overloaded bits and pieces), and for hardware breakpoints (an approach for solving reproducible memory corruption: comb…

This is a great comment. Most of the value I get out of using a debugger - I work in game dev - is from these, often in concert. Even before I start setting data breakpoints, though, I often find myself examining heap memory with the process paused to give myself sufficient context to do more informed exploration later. In the last year or so I've also started using Visual Studio's "action" breakpoints, a sort of runtime configurable printf, once I've identified areas of interest.

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

#107

Post by Shorel »

int_19h wrote: post #96
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.

printf debugging doesn't work when your code already crashed, and all you have is the process dump (and if you're very lucky, it's a heap dump, not just stacks).

You can do binary search with the line where the printf statement is, and eventually you will find the line with the error.

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

#108

Post by fanf2 »

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…

Thanks for those deeper details, enlightening!

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

#109

Post by v_lisivka »

floofy222 wrote: post #44
keldaris wrote: post #39

Those of us who have compute-bound workloads (scientific simulations in my case, but this often comes up in gamedev and elsewhere) often complain about how unusably slow debug builds impede our workflow in C++. One fairly common solution to this in extreme cases is sticking to a mostly C-like subset of the language or just using C. I don't have much experience with Rust, but judging by the results here, debug builds…

> How do Rust programmers deal with this? You compile with -C opt-level=1.

Cargo.toml:

  [profile.dev]
  #opt-level = "s"
  opt-level = 2

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

#110

Post by pjmlp »

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?

Borland even used to have a few marketing ads about JIT debugging, by making use of Dr. Watson infrastructure on Win16.
Post reply on HN