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

Current hardware trends make C++ exceptions harder to justify

open-std.org

Post reply on HN
Print view View original

471–480 of 516 posts

Re: Current hardware trends make C++ exceptions harder to justify

#471

Post by ncmncm »

ModernMech wrote: post #463
ncmncm wrote: post #443

Earlier quoted context omitted.

That is code for "it is evolving and I cannot be bothered to keep up". All languages that are actually useful evolve. They get features that other people need, and you don't, just yet. Some of those features do turn out not to be perfect, because they are made by humans. Comparing an old language to a new language, the new language will have many fewer of those both because it leaves many old things behind, and becau…

> "it is evolving and I cannot be bothered to keep up" No, I actually teach C++ and have been keeping up with it for decades. It was the second language I learned in 1994 and I still code in it professionally today. > Give it time, and it will accumulate "incoherence" of its own; the faster it evolves, the faster that happens. Like I pointed out with Matlab, it’s a much older language compared to c++ yet is mostly co…

If you teach C++, I can only feel sorry for your students, having such a confused teacher.

Re: Current hardware trends make C++ exceptions harder to justify

#472

Post by ModernMech »

ncmncm wrote: post #470
ModernMech wrote: post #447

Earlier quoted context omitted.

But they’re still not on the latest version…

People not using the latest Standard are waiting for support within their particular environment, not because they want to stay with a less performant version of the language.

But this is what you said:

> Failing to use the new feature is just failing to write code the best way that is available right now. In 2013 you had no choice but to do it the old way; but you don't have to anymore, because the language and std library have caught up with you.

What I hear you saying is that failing to use new features is a failure to write the best code available, and that before maybe you didn't have a choice but not anymore.

And yet, huge chunk of C++ devs are forbidden by their organizations from using various C++ features that have been added throughout the years. It's not just C++ 17 but it goes back even further. This is the whole point of TFA. So it's not just that people are "waiting" for tools to catch up, unless you have evidence of this.

Re: Current hardware trends make C++ exceptions harder to justify

#473

Post by ModernMech »

ncmncm wrote: post #469
ModernMech wrote: post #448

Earlier quoted context omitted.

Matlab is one of the top 20 programming languages in the world still after 60 years according to the TIOBE index [0]. It has maintained a large user-base and achieved profitability over this time, not by adopting every PL trend that has come and gone, but by adapting to new developments while staying focused on its essence as a language. It proves you can stay current without doing what C++ is doing. Matlab's usage i…

Citing TIOBE instantly demonstrates a fatally bankrupt argument: changes in TIOBE ratings have essentially nothing to do with actual usage, or with anything else quantifiable. TIOBE is statistical noise. You would equally meaningfully cite your tea leaves, or crows flying overhead.

Okay, well then I suppose you have a better citation for your unsupported assertion that Matlab has been in decline for many years. I've backed up most of my assertions with citations, I think it's time you brought some sources to the discussion. What is your basis for anything that you've been saying here?

I mean, if TIOBE was really statistical noise as your claim, there wouldn't be clear trends in industry reflected in the data, like the rise of Python in the last few years. And yet we see it, so clearly it's measuring something.

Re: Current hardware trends make C++ exceptions harder to justify

#474

Post by ModernMech »

ncmncm wrote: post #471
ModernMech wrote: post #463

Earlier quoted context omitted.

> "it is evolving and I cannot be bothered to keep up" No, I actually teach C++ and have been keeping up with it for decades. It was the second language I learned in 1994 and I still code in it professionally today. > Give it time, and it will accumulate "incoherence" of its own; the faster it evolves, the faster that happens. Like I pointed out with Matlab, it’s a much older language compared to c++ yet is mostly co…

If you teach C++, I can only feel sorry for your students, having such a confused teacher.

Please leave the personal attacks out of this, thanks. I've said nothing personally against you and yet you've turned to calling into question my profession rather than the points I've raised. I understand maybe it may feel like I'm attacking you personally as I'm criticizing a language which I gather you are very fond of, but criticizing C++ is not criticizing you, and I would appreciate if you show me the same respect I've shown you. That's not what this site is for, and if you want to engage in that kind of back and forth I'd kindly decline.

My students give me high marks, my department (which includes faculty who have contributed to C++ spec over the years) is satisfied with my teaching, and I graduate students that go on to work at top companies and research labs around the world. I'm doing my job just fine, let's stick to talking about C++.

Re: Current hardware trends make C++ exceptions harder to justify

#475

Post by ncmncm »

astrange wrote: post #446
ncmncm wrote: post #432

Earlier quoted context omitted.

It suffices, for cache footprint, for cold code to be on a different cache line, maybe 64 bytes away. For virtual memory footprint, being on another page suffices, ~4k away. Nothing benefits from being at the "end of the program". Machines do still charge an extra cycle for branches taken vs. not, so it matters whether you expect to take it. Negligibly few things never return; most of those abort. Performance of thos…

> Nothing benefits from being at the "end of the program". It's not about the benefit, that's just the easiest way to implement it - put it in a different TEXT section and let the linker move it. Although, there is a popular desktop ARM CPU with 16KB pages. > Machines do still charge an extra cycle for branches taken vs. not, so it matters whether you expect to take it. Current generation CPUs can issue one taken bra…

More prediction is not, in fact, always better.

Specifically, a prediction is not better when it makes no difference. Then, it is worse, because it consumes a resource that would better be applied in a different place where it could make a difference.

Exceptions are the perfect example of a case where any prediction expenditure would be wasted; except predicting that no exception will be thrown. It is always better to predict no exception is thrown, because only the non-throwing case can benefit.

Running ahead and pre-computing results that would be thrown away if an exception is thrown is a pure win: With no exception, you are far ahead; with an exception, there is no useful work to be sped up, it is all just overhead anyway.

This is similar to a busy-wait: you are better off to have leaving the wait predicted, because that reduces your response latency, even though history predicts that you will continue waiting. This is why there is now a special busy-wait instruction that does not consume a branch prediction slot. (It also consumes no power, because it just sleeps until the cache line being watched shows an update.)

Re: Current hardware trends make C++ exceptions harder to justify

#476

Post by worik »

gpderetta wrote: post #449
worik wrote: post #396

Earlier quoted context omitted.

What dumb design. I thought the constructor returned a pointer to the memory created. No return? Stupid!

FWIW, constructors do not "create" (I assume you mean allocate) memory. That's the job of operator new. A constructor, given a block of untyped memory, will construct an object in it.

Right.

Been a long time.

I would still expect a constructor to return. How can you tell if it failed?

Re: Current hardware trends make C++ exceptions harder to justify

#477

Post by ncmncm »

jstimpfle wrote: post #457
ncmncm wrote: post #441

Earlier quoted context omitted.

That "if" that guards the throw is the same "if" as would guard the error return. It is the second "if", in the caller, checking the returned result, that up-to-doubles your branch-prediction cache footprint. On, yes, the hot path. Program structure corruption is another problem. They add. Bad code is a tax on all of us.

Which is what I said. And I still don't see how most code that potentially returns errors would be on a hot path. Code that is really on a hot path should probably not call into generic code anyway, and/or that called code should be inlined. I don't know, as a C programmer, somehow I rarely run into these situations where I have to check error return values. I think the reason is that I work hard to avoid wrappers ar…

Inlined code still has all the "if" checks of the original code, just without the actual "jsr" and "ret" instructions in between.

Comparing a good C coder to a bad C++ coder is meaningless: By definition, a bad coder makes bad choices, whatever the language.

Bad code is slow in a place where speed matters. It is improved by making it fast. Language choice does not affect this.

What language choice does affect is whether you can afford to spend the attention needed to make the code fast. C++ provides tools to offload busywork, freeing your attention to apply to what matters. It remains the programmer's job to choose that.

Re: Current hardware trends make C++ exceptions harder to justify

#478

Post by ncmncm »

kllrnohj wrote: post #444
randyrand wrote: post #399

Earlier quoted context omitted.

> Point performance is the worst way to decide about error handling. My point is exactly that. It's more important to have a single common way of doing error handling than it is to have a small perf improvement. That's why I recommend return values. You'll never hit a perf problem with them. Exceptions cannot be used in code hot paths (~thousands of iterations) when it's not a small perf problem anymore. Therefore, t…

> That's why I recommend return values. You'll never hit a perf problem with them. > Exceptions cannot be used in code hot paths (~thousands of iterations) when it's not a small perf problem anymore. You should read the paper in the link. Both of your claims here are exactly backward. The problem is "just" that exceptions don't scale across multiple threads due to internally using a global lock. They are otherwise mu…

Yes. The article author's mistake was actually throwing those exceptions too often. For arithmetic errors, NaN is usually the better choice.

Re: Current hardware trends make C++ exceptions harder to justify

#479

Post by ncmncm »

ModernMech wrote: post #472
ncmncm wrote: post #470

Earlier quoted context omitted.

People not using the latest Standard are waiting for support within their particular environment, not because they want to stay with a less performant version of the language.

But this is what you said: > Failing to use the new feature is just failing to write code the best way that is available right now. In 2013 you had no choice but to do it the old way; but you don't have to anymore, because the language and std library have caught up with you. What I hear you saying is that failing to use new features is a failure to write the best code available, and that before maybe you didn't have…

Organizational inertia is a problem, but not a problem that a language or Standard can fix.

When an organizational logjam is broken, programmers can immediately switch over to the better, more modern way of coding enabled by the newer Standard they are allowed to use. If they were on C++98, and now they can use C++14, they are still better off than before, even if the current Standard is C++20: they will be able to code according to best practices for C++14, which are better than for C++98.

Re: Current hardware trends make C++ exceptions harder to justify

#480

Post by ncmncm »

ModernMech wrote: post #474
ncmncm wrote: post #471

Earlier quoted context omitted.

If you teach C++, I can only feel sorry for your students, having such a confused teacher.

Please leave the personal attacks out of this, thanks. I've said nothing personally against you and yet you've turned to calling into question my profession rather than the points I've raised. I understand maybe it may feel like I'm attacking you personally as I'm criticizing a language which I gather you are very fond of, but criticizing C++ is not criticizing you, and I would appreciate if you show me the same resp…

I apologize. I was out of line to write that.
Post reply on HN