| Mel <mel@zzzzz.com>: Aug 30 01:37PM +0200 On Fri, 30 Aug 2019 14:08:47 +0300, Paavo Helde > > On Fri, 30 Aug 2019 10:39:19 +0200, Bonita Montero > >> The non-throw-case takes almost no or no performance. > > That's no true. You have to install handlers evrry time or prepare tbla > >> Evaluating return-codes is simply a magnitude slower. > > This is especially not true. > Your information is out of date for a couple of decades. The current C++ > compilers have implemented zero cost exceptions (in the no-throw path) > already long time ago. That's simply impossible. -- Press any key to continue or any other to quit |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 30 01:47PM +0200 > when they /are/ thrown. But "usually" is not "always". And for some > situations, it is the worst case performance - the speed when there is a > problem - that is critical. The case when an exception is thrown isn't performance-relevant as this occurs when there's an resource- or I/O-collapse. > Fair enough - though convenience is also a subjective matter. That's rather not subjective here because evaluating return-codes on every call-level is a lot of work. > some people like and others dislike. And they can't pass through > functions compiled without knowledge of the exceptions - such as C > functions compiled by a C compiler. Can you read what I told above? >> Even on small CPUs the performance of processing a resurce- or I/O >> -collapse doesn't count. > Incorrect. No, correct. > Performance under the worst case is often a critical feature of high > reliability systems. When you have a resource or I/O-collapse, you don't have reliability anyway. >> That's true, but then you wouldn't use C++. > Nonsense. There are many good reasons to use C++, and many features > that can be used, without leading to any inefficiency or bloat. Almost the whole standard-libary uses an allocaor which might throw bad_alloc; not to use the standard-library isn't really C++. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 30 01:48PM +0200 > That's simply impossible. If I wouldn't know how it is possible I would think the same. |
| Paavo Helde <myfirstname@osa.pri.ee>: Aug 30 03:18PM +0300 On 30.08.2019 14:37, Mel wrote: > path) >> already long time ago. > That's simply impossible. See e.g. http://www.ut.sco.com/developers/products/ehopt.pdf From that paper: "Most high-performance EH implementations use the commonly known table-driven approach. The goal of this approach is to present zero execution-time overhead, until and unless an exception is thrown." The paper acknowledges some deficiencies with this goal, mainly missing some optimization opportunities, then goes further to solve a part of them. Note this paper is from 1998. The compiler technology has moved forward meanwhile. It might be there is some minimal machine code needed for EH like a register load at function entrance. This does not make it non-zero cost because the alternative is to use an error return, which would also be at least a register load plus a branching instruction for checking it in the caller. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 30 02:24PM +0200 > Note this paper is from 1998. The compiler technology > has moved forward meanwhile. That this is from 1998 doesn't mean that it is relevant to each imple- mentation. Win32 had structured exception handling from the beginning with NT 3.1. And the exception-handling-implementation of the first Visual C++ version was built on top of that. So Microsoft hadn't any choice to revert that for newer version of VC++. |
| "Öö Tiib" <ootiib@hot.ee>: Aug 30 06:30AM -0700 On Friday, 30 August 2019 11:33:36 UTC+3, Mel wrote: > > } > > That does not seem to fit with what you describe. > Try to do something with x... But it seemingly did. Do you mean where I need traits? Like in: impl<T: Display + PartialOrd> Point<T> { fn cmp_display(&self) { if self.x >= self.y { //< here I need PartialOrd // here I need Display println!("The largest member is x = {}", self.x); } else { println!("The largest member is y = {}", self.y); } } } That seems Ok type-safety feature. |
| Mel <mel@zzzzz.com>: Aug 30 03:42PM +0200 On Fri, 30 Aug 2019 15:18:21 +0300, Paavo Helde > On 30.08.2019 14:37, Mel wrote: > > On Fri, 30 Aug 2019 14:08:47 +0300, Paavo Helde <myfirstname@osa.pri.ee> > table-driven approach. The goal of this approach is to present zero > execution-time overhead, until and unless an exception is thrown." > The paper acknowledges some deficiencies with this goal, mainly missing > some optimization opportunities, then goes further to solve a part of them. > Note this paper is from 1998. The compiler technology has moved forward > meanwhile. > It might be there is some minimal machine code needed for EH like a > register load at function entrance. This does not make it non-zero cost > because the alternative is to use an error return, which would also be > at least a register load plus a branching instruction for checking it in > the caller. I already said 'space or time' -- Press any key to continue or any other to quit |
| Mel <mel@zzzzz.com>: Aug 30 03:43PM +0200 On Fri, 30 Aug 2019 14:24:24 +0200, Bonita Montero > > Note this paper is from 1998. The compiler technology > > has moved forward meanwhile. > That this is from 1998 doesn't mean that it is relevant to each imple- > mentation. Win32 had structured exception handling from the beginning > with NT 3.1. And the exception-handling-implementation of the first > Visual C++ version was built on top of that. So Microsoft hadn't any > choice to revert that for newer version of VC++. Under windows there is run tme cost because of that... -- Press any key to continue or any other to quit |
| Mel <mel@zzzzz.com>: Aug 30 03:59PM +0200 On Fri, 30 Aug 2019 06:30:30 -0700 (PDT), Öö Tiib<ootiib@hot.ee> wrote: > t.ee= > > > > wrote: > > > > > > Rust generics are interface based. You cant do anything with > > > > > > generic type unless you tell which interfaces satisfies. > > > > > Perhaps I don't understand what you mean. Can you bring example? > > > > > The main point of generics seems to work in Rust about like in > > C++ > > > > Not even close. Imagin that you have to cite what abstract base > > > That does not seem to fit with what you describe. > > Try to do something with x... > But it seemingly did. No it just returned value. Don't try to win argument when you don't have any... > Do you mean where I need traits? Like in: You always need traits even to initialize value... > That seems Ok type-safety feature. It is not safety feature it is how gemerics are implemented in rust. Same way it works in Haskell. -- Press any key to continue or any other to quit |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 30 04:23PM +0200 >> Microsoft hadn't any choice to revert that for newer version >> of VC++. > Under windows there is run tme cost because of that... No, structured exception handling an the C++ Eh built on top of that installs unwind-handleres linked through the stack on each call-level that needs special unwind-semantics. With the x64-Windows SEH was re-defined table-driven so that both SEH and C++-EH have an almost-zero-overhead. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Aug 30 02:40PM > that needs special unwind-semantics. > With the x64-Windows SEH was re-defined table-driven so that both SEH > and C++-EH have an almost-zero-overhead. Zero *run time* overhead at the cost of *space* overhead. -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| "Öö Tiib" <ootiib@hot.ee>: Aug 30 07:42AM -0700 On Friday, 30 August 2019 17:00:00 UTC+3, Mel wrote: > > But it seemingly did. > No it just returned value. Don't try to win argument when you don't > have any... I did not try to win argument, I admit I have none and I just did not understand your argument (may be I still don't). > > Do you mean where I need traits? Like in: > You always need traits even to initialize value... It is Ok I suppose. Writing those "std::enable_if"s for C++<=17 templates is most tedious and ugly. > > That seems Ok type-safety feature. > It is not safety feature it is how gemerics are implemented in rust. > Same way it works in Haskell. It feels similar to required upcoming concepts/constraints of C++20. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Aug 30 02:44PM >> It is not safety feature it is how gemerics are implemented in rust. >> Same way it works in Haskell. > It feels similar to required upcoming concepts/constraints of C++20. Well, C++ template types are structural and Rust nominative. That is whole difference. -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 30 04:57PM +0200 >> With the x64-Windows SEH was re-defined table-driven so that both SEH >> and C++-EH have an almost-zero-overhead. > Zero *run time* overhead at the cost of *space* overhead. We're talking abot Windows-computers and not Ardino Unos. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 30 07:19PM +0200 >> bili naoruzani. -- Mladen Gogala > IMHO, you are barking up the wrong tree. > EH is bad not because it's slow or costly, but because of its messy semantics. What's messy with the semantics? |
| Juha Nieminen <nospam@thanks.invalid>: Aug 30 09:03PM > path) >> already long time ago. > That's simply impossible. That's like saying that a longjmp() being zero-overhead (with respect to all the code that's executed when no jump is done) is "impossible". You can set up a long jump, and no other code that you call gets any slower or suffers from any overhead. It's only when something triggers that long jump that something special happens. Exceptions are not identical to that, but it's not that far off. But the end result is that if no exception is thrown, no code suffers from any overhead. |
| Ian Collins <ian-news@hotmail.com>: Aug 31 09:42AM +1200 On 30/08/2019 20:43, Mel wrote: >> The non-throw-case takes almost no or no performance. > That's no true. You have to install handlers evrry time or prepare > tbla for each function at program start... Have you actually measured the difference? I have on several occasions and yes, the no-throw path with exceptions is faster (even if only slightly) than testing error returns. It is also foolproof.. -- Ian. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 30 11:53PM +0200 > It is also foolproof.. It is not absolutely foolproof because there might be exceptions that will be uncaught. That's the reason I like checked exceptions in Java so much. But it is by magnitudes more convenient as to return and evaluate return-codes. |
| "Öö Tiib" <ootiib@hot.ee>: Aug 30 12:15AM -0700 On Friday, 30 August 2019 09:28:47 UTC+3, David Brown wrote: > variant types. Perhaps he was less used to complex types and found > "QMap<QString, QVariant>" to be simpler (in his eyes) than > "QMap<QSTring, QMap<QString, int> >". Yes, it may be was translated in his mind from Python's Qt support (like PySide2.QtCore) where unneeded QVariant usage was harder to notice. And what was needed was probably QMap<QSTring, QMap<int, QString> >" anyway. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment