"Is C++ fast?"

[Lynn McGuire]

"Is C++ fast?"
https://www.osnews.com/story/129217/is-c-fast/

"A library that I work on often these days, meshoptimizer, has changed
over time to use fewer and fewer C++ library features, up until the
current state where the code closely resembles C even though it uses
some C++ features. There have been many reasons behind the changes –
dropping C++11 requirement allowed me to make sure anybody can compile
the library on any platform, removing std::vector substantially improved
performance of unoptimized builds, removing algorithm includes sped up
compilation. However, I’ve never quite taken the leap all the way to C
with this codebase. Today we’ll explore the gamut of possible C++
implementations for one specific algorithm, mesh simplifier, henceforth
known as simplifier.cpp, and see if going all the way to C is worthwhile."
https://zeuxcg.org/2019/01/17/is-c-fast/

Lynn

[Mr Flibble]

Who cares about the performance of unoptimized builds? I certainly don't.
std::vector will be slower probably due to checked iterators which can be
highly useful in finding problems in debug builds (and you can also turn
that feature off).

Seriously changing an existing C++ codebase to make it pre-C++11 really is
a dumb idea. This is 2019.

/Flibble

--
“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” –
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."

[Ian Collins]

On 20/01/2019 08:18, Mr Flibble wrote:
> On 19/01/2019 19:13, Lynn McGuire wrote:
>> "Is C++ fast?"
>>    https://www.osnews.com/story/129217/is-c-fast/
>>
>> "A library that I work on often these days, meshoptimizer, has changed
>> over time to use fewer and fewer C++ library features, up until the
>> current state where the code closely resembles C even though it uses some
>> C++ features. There have been many reasons behind the changes – dropping
>> C++11 requirement allowed me to make sure anybody can compile the library
>> on any platform, removing std::vector substantially improved performance
>> of unoptimized builds, removing algorithm includes sped up compilation.
>> However, I’ve never quite taken the leap all the way to C with this
>> codebase. Today we’ll explore the gamut of possible C++ implementations
>> for one specific algorithm, mesh simplifier, henceforth known as
>> simplifier.cpp, and see if going all the way to C is worthwhile."
>>    https://zeuxcg.org/2019/01/17/is-c-fast/
>
> Who cares about the performance of unoptimized builds? I certainly don't.
> std::vector will be slower probably due to checked iterators which can be
> highly useful in finding problems in debug builds (and you can also turn
> that feature off).
>
> Seriously changing an existing C++ codebase to make it pre-C++11 really is
> a dumb idea. This is 2019.

What he said!

--
Ian.

[woodb...@gmail.com]

On Saturday, January 19, 2019 at 1:18:36 PM UTC-6, Mr Flibble wrote:
> On 19/01/2019 19:13, Lynn McGuire wrote:
> > "Is C++ fast?"
> >    https://www.osnews.com/story/129217/is-c-fast/
> >
> > "A library that I work on often these days, meshoptimizer, has changed
> > over time to use fewer and fewer C++ library features, up until the
> > current state where the code closely resembles C even though it uses some
> > C++ features. There have been many reasons behind the changes – dropping
> > C++11 requirement allowed me to make sure anybody can compile the library
> > on any platform, removing std::vector substantially improved performance
> > of unoptimized builds, removing algorithm includes sped up compilation.
> > However, I’ve never quite taken the leap all the way to C with this
> > codebase. Today we’ll explore the gamut of possible C++ implementations
> > for one specific algorithm, mesh simplifier, henceforth known as
> > simplifier.cpp, and see if going all the way to C is worthwhile."
> >    https://zeuxcg.org/2019/01/17/is-c-fast/
>
> Who cares about the performance of unoptimized builds?

I do.

> I certainly don't.
> std::vector will be slower probably due to checked iterators which can be
> highly useful in finding problems in debug builds (and you can also turn
> that feature off).
>
> Seriously changing an existing C++ codebase to make it pre-C++11 really is
> a dumb idea. This is 2019.
>

I'm in the middle -- I require 2011 C++ but that's
as far back as I can go to reach out. I've wondered
if 2011 C++ is the new C.



Brian
Ebenezer Enterprises - Enjoying programming again.
https://github.com/Ebenezer-group/onwards

[Ian Collins]

On 20/01/2019 09:56, woodb...@gmail.com wrote:
> On Saturday, January 19, 2019 at 1:18:36 PM UTC-6, Mr Flibble wrote:
>> On 19/01/2019 19:13, Lynn McGuire wrote:
>>> "Is C++ fast?"
>>>    https://www.osnews.com/story/129217/is-c-fast/
>>>
>>> "A library that I work on often these days, meshoptimizer, has changed
>>> over time to use fewer and fewer C++ library features, up until the
>>> current state where the code closely resembles C even though it uses some
>>> C++ features. There have been many reasons behind the changes – dropping
>>> C++11 requirement allowed me to make sure anybody can compile the library
>>> on any platform, removing std::vector substantially improved performance
>>> of unoptimized builds, removing algorithm includes sped up compilation.
>>> However, I’ve never quite taken the leap all the way to C with this
>>> codebase. Today we’ll explore the gamut of possible C++ implementations
>>> for one specific algorithm, mesh simplifier, henceforth known as
>>> simplifier.cpp, and see if going all the way to C is worthwhile."
>>>    https://zeuxcg.org/2019/01/17/is-c-fast/
>>
>> Who cares about the performance of unoptimized builds?
>
> I do.

Why?

>> I certainly don't.
>> std::vector will be slower probably due to checked iterators which can be
>> highly useful in finding problems in debug builds (and you can also turn
>> that feature off).
>>
>> Seriously changing an existing C++ codebase to make it pre-C++11 really is
>> a dumb idea. This is 2019.
>>
>
> I'm in the middle -- I require 2011 C++ but that's
> as far back as I can go to reach out. I've wondered
> if 2011 C++ is the new C.

Why don't you just wrote C++11?

--
Ian.

[David Brown]

On 19/01/2019 22:35, Ian Collins wrote:
> On 20/01/2019 09:56, woodb...@gmail.com wrote:
>> On Saturday, January 19, 2019 at 1:18:36 PM UTC-6, Mr Flibble wrote:

>>> Who cares about the performance of unoptimized builds?
>>
>> I do.
>
> Why?

For the same reason people care how fast their car can go in first gear.

>
>>> I certainly don't.
>>> std::vector will be slower probably due to checked iterators which
>>> can be
>>> highly useful in finding problems in debug builds (and you can also turn
>>> that feature off).
>>>
>>> Seriously changing an existing C++ codebase to make it pre-C++11
>>> really is
>>> a dumb idea.  This is 2019.
>>>
>>
>> I'm in the middle -- I require 2011 C++ but that's
>> as far back as I can go to reach out.  I've wondered
>> if 2011 C++ is the new C.

C11 is the new C. C++11 is a milestone in the development of C++, but
it is not C.

[Ian Collins]

On 20/01/2019 11:49, David Brown wrote:
> On 19/01/2019 22:35, Ian Collins wrote:
>> On 20/01/2019 09:56, woodb...@gmail.com wrote:
>>> On Saturday, January 19, 2019 at 1:18:36 PM UTC-6, Mr Flibble wrote:
>
>>>> Who cares about the performance of unoptimized builds?
>>>
>>> I do.
>>
>> Why?
>
> For the same reason people care how fast their car can go in first gear.

That's a useful number - especially if it can get from 0 to 60 without
changing up :)

--
Ian.

[Michael Powell]

On Saturday, January 19, 2019 at 2:18:36 PM UTC-5, Mr Flibble wrote:
> On 19/01/2019 19:13, Lynn McGuire wrote:
> > "Is C++ fast?"
> >    https://www.osnews.com/story/129217/is-c-fast/
> >
> > "A library that I work on often these days, meshoptimizer, has changed
> > over time to use fewer and fewer C++ library features, up until the
> > current state where the code closely resembles C even though it uses some
> > C++ features. There have been many reasons behind the changes – dropping
> > C++11 requirement allowed me to make sure anybody can compile the library
> > on any platform, removing std::vector substantially improved performance
> > of unoptimized builds, removing algorithm includes sped up compilation.
> > However, I’ve never quite taken the leap all the way to C with this
> > codebase. Today we’ll explore the gamut of possible C++ implementations
> > for one specific algorithm, mesh simplifier, henceforth known as
> > simplifier.cpp, and see if going all the way to C is worthwhile."
> >    https://zeuxcg.org/2019/01/17/is-c-fast/
>
> Who cares about the performance of unoptimized builds? I certainly don't.
> std::vector will be slower probably due to checked iterators which can be
> highly useful in finding problems in debug builds (and you can also turn
> that feature off).
>
> Seriously changing an existing C++ codebase to make it pre-C++11 really is
> a dumb idea. This is 2019.

Boy, not kidding, I agree. Dumb, even imbecilic, given standards are well beyond even C++1y at this point, I think, and working on C++2z standards.

Now, that said, I'm not suggesting because there is a fancy new shiny thing you should necessarily adopt it just because it's there; along the same lines as Stroustrup himself would encourage: KEEP IT SIMPLE. But if there is something you can leverage from a standard, by all means, DO IT!

[Chris M. Thomasson]

0 to 60 in first gear: Exotic cars are nice!

http://newmotoring.com/what-cars-will-do-60mph-in-first-gear

[Robert Wessel]

Oddly they didn't include the Tesla S. Admittedly it one has only one
gear, but it'll get well past sixty in that one. A base model 2012 S
could do 0-60 in 5.9s. By 2015 (and the article is from 2016), you
could get a 2.6s 0-60 in your S with the "Ludicrous Mode" option.

[woodb...@gmail.com]

On Saturday, January 19, 2019 at 3:35:43 PM UTC-6, Ian Collins wrote:
> On 20/01/2019 09:56, woodb...@gmail.com wrote:
> > On Saturday, January 19, 2019 at 1:18:36 PM UTC-6, Mr Flibble wrote:
> >> On 19/01/2019 19:13, Lynn McGuire wrote:
> >>> "Is C++ fast?"
> >>>    https://www.osnews.com/story/129217/is-c-fast/
> >>>
> >>> "A library that I work on often these days, meshoptimizer, has changed
> >>> over time to use fewer and fewer C++ library features, up until the
> >>> current state where the code closely resembles C even though it uses some
> >>> C++ features. There have been many reasons behind the changes – dropping
> >>> C++11 requirement allowed me to make sure anybody can compile the library
> >>> on any platform, removing std::vector substantially improved performance
> >>> of unoptimized builds, removing algorithm includes sped up compilation.
> >>> However, I’ve never quite taken the leap all the way to C with this
> >>> codebase. Today we’ll explore the gamut of possible C++ implementations
> >>> for one specific algorithm, mesh simplifier, henceforth known as
> >>> simplifier.cpp, and see if going all the way to C is worthwhile."
> >>>    https://zeuxcg.org/2019/01/17/is-c-fast/
> >>
> >> Who cares about the performance of unoptimized builds?
> >
> > I do.
>
> Why?

Some of my software is meant to be portable.
Just because some compilers do a good job of
optimizing doesn't mean all of them will.

There may also be some compile-time advantage
to minimizing your dependency on optimizers.

>
> >> I certainly don't.
> >> std::vector will be slower probably due to checked iterators which can be
> >> highly useful in finding problems in debug builds (and you can also turn
> >> that feature off).
> >>
> >> Seriously changing an existing C++ codebase to make it pre-C++11 really is
> >> a dumb idea. This is 2019.
> >>
> >
> > I'm in the middle -- I require 2011 C++ but that's
> > as far back as I can go to reach out. I've wondered
> > if 2011 C++ is the new C.
>
> Why don't you just wrote C++11?
>

Let me guess. You haven't adopted :: prefixes yet.
https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/genz.cc


Brian
Ebenezer Enterprises
http://webEbenezer.net

[Ian Collins]

Why would anyone adopt such a superfluous abomination?

No sane programmer would either overload C standard library function
names or introduce their own namespace std.

--
Ian

[woodb...@gmail.com]

Sure, but there are insane and/or malicious hackers out
there.

[Ian Collins]

So how does a :: prefixe solve that problem?

--
Ian.

[Chris M. Thomasson]

Agreed. I think "Ludicrous Mode" costs a lost as an add-on?

[Chris M. Thomasson]

For some reason, that typo makes me think of:

https://youtu.be/J-wl8j-F9Tk

Leisure Suit Larry 6: La Costa Lotta

Or wasting away in the Land of Lost Wages...

[Jorgen Grahn]

On Sun, 2019-01-20, woodb...@gmail.com wrote:
> On Saturday, January 19, 2019 at 3:35:43 PM UTC-6, Ian Collins wrote:
>> On 20/01/2019 09:56, woodb...@gmail.com wrote:
>> > On Saturday, January 19, 2019 at 1:18:36 PM UTC-6, Mr Flibble wrote:
>> >> On 19/01/2019 19:13, Lynn McGuire wrote:
>> >>> "Is C++ fast?"
>> >>>    https://www.osnews.com/story/129217/is-c-fast/
>> >>>
>> >>> "A library that I work on often these days, meshoptimizer, has changed
>> >>> over time to use fewer and fewer C++ library features, up until the
>> >>> current state where the code closely resembles C even though it uses some
>> >>> C++ features. There have been many reasons behind the changes – dropping
>> >>> C++11 requirement allowed me to make sure anybody can compile the library
>> >>> on any platform, removing std::vector substantially improved performance
>> >>> of unoptimized builds, removing algorithm includes sped up compilation.
>> >>> However, I’ve never quite taken the leap all the way to C with this
>> >>> codebase. Today we’ll explore the gamut of possible C++ implementations
>> >>> for one specific algorithm, mesh simplifier, henceforth known as
>> >>> simplifier.cpp, and see if going all the way to C is worthwhile."
>> >>>    https://zeuxcg.org/2019/01/17/is-c-fast/
>> >>
>> >> Who cares about the performance of unoptimized builds?
>> >
>> > I do.
>>
>> Why?
>
> Some of my software is meant to be portable. Just because some
> compilers do a good job of optimizing doesn't mean all of them will.

A C++ compiler with a low-performing or buggy optimizer is virtually
useless, as far as I can tell. There will be a runtime penalty for
writing normal C++ code.

When I started programming in C in the early 1990s, many didn't trust
or use their optimizers. Perhaps partly for good reasons ... but it
also didn't matter as much in old C. I wonder if that's where the
quoted author is coming from.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Robert Wessel]

On Sat, 19 Jan 2019 21:10:49 -0800, "Chris M. Thomasson "

I think that on the S, Ludicrous mode is now standard with on the
P100D model, about $133K (list).

[James Kuyper]

On 1/19/19 23:05, Ian Collins wrote:
> On 20/01/2019 16:59, woodb...@gmail.com wrote:
>> On Saturday, January 19, 2019 at 9:38:23 PM UTC-6, Ian Collins wrote:
>>> On 20/01/2019 16:31, woodb...@gmail.com wrote:

...

>>>> Let me guess. You haven't adopted :: prefixes yet.
>>>
>>> Why would anyone adopt such a superfluous abomination?
>>>
>>> No sane programmer would either overload C standard library function
>>> names or introduce their own namespace std.
>>>
>>
>> Sure, but there are insane and/or malicious hackers out
>> there.
>
> So how does a :: prefixe solve that problem?

Whenever you use such a prefix, you prevent yourself from accidentally
using a corresponding identifier defined by such programmers. Of course,
if you're absolutely certain that your code will never have to work with
code written by such people, then you don't need such prefixes.

[Scott Lurndal]

Ian Collins <ian-...@hotmail.com> writes:
> Thunderbird/60.2.1
>In-Reply-To: <3KK0E.12566$ox....@fx05.fr7>
>Content-Language: en-US
>X-Received-Bytes: 2295
>X-Received-Body-CRC: 766037843

Disagree. There are situations where C++11 isn't supported (compat.
with third-party libraries and existing development environments being a typical driver).

When you have thousands of servers running RHEL6 and third-party software,
upgrading the entire farm is a massive undertaking (including verifying
upgraded tools (source control, grid management, simulation tools, IC
design and layout tools, open source software, libraries and kernels for
compatability with existing flows). We have, for example a great deal
of python2 code, which becomes a second-class citizen in newer distributions.
Nobody is going to spend the time or dollars to upgrade the python code
for python3.

We have also discontinued use of various C++ features in certain
parts of the codebase (such as soi disant smart pointers) for performance reasons.

Sure, we'll eventually move forward, but that's a long process, and in the
mean time, pre-C++11 code is required.

[Mr Flibble]

On 20/01/2019 16:31, Scott Lurndal wrote:
> Ian Collins <ian-...@hotmail.com> writes:
>> Thunderbird/60.2.1
>> In-Reply-To: <3KK0E.12566$ox....@fx05.fr7>
>> Content-Language: en-US
>> X-Received-Bytes: 2295
>> X-Received-Body-CRC: 766037843
>>
>> On 20/01/2019 08:18, Mr Flibble wrote:
>>> On 19/01/2019 19:13, Lynn McGuire wrote:
>>>> "Is C++ fast?"

>>>>    https://www.osnews.com/story/129217/is-c-fast/

>>>>
>>>> "A library that I work on often these days, meshoptimizer, has changed
>>>> over time to use fewer and fewer C++ library features, up until the
>>>> current state where the code closely resembles C even though it uses some

>>>> C++ features. There have been many reasons behind the changes – dropping

>>>> C++11 requirement allowed me to make sure anybody can compile the library
>>>> on any platform, removing std::vector substantially improved performance
>>>> of unoptimized builds, removing algorithm includes sped up compilation.

>>>> However, I’ve never quite taken the leap all the way to C with this
>>>> codebase. Today we’ll explore the gamut of possible C++ implementations

>>>> for one specific algorithm, mesh simplifier, henceforth known as
>>>> simplifier.cpp, and see if going all the way to C is worthwhile."

>>>>    https://zeuxcg.org/2019/01/17/is-c-fast/

>>>
>>> Who cares about the performance of unoptimized builds? I certainly don't.
>>> std::vector will be slower probably due to checked iterators which can be
>>> highly useful in finding problems in debug builds (and you can also turn
>>> that feature off).
>>>
>>> Seriously changing an existing C++ codebase to make it pre-C++11 really is
>>> a dumb idea. This is 2019.
>>
>> What he said!
>
> Disagree. There are situations where C++11 isn't supported (compat.
> with third-party libraries and existing development environments being a typical driver).
>
> When you have thousands of servers running RHEL6 and third-party software,
> upgrading the entire farm is a massive undertaking (including verifying
> upgraded tools (source control, grid management, simulation tools, IC
> design and layout tools, open source software, libraries and kernels for
> compatability with existing flows). We have, for example a great deal
> of python2 code, which becomes a second-class citizen in newer distributions.
> Nobody is going to spend the time or dollars to upgrade the python code
> for python3.
>
> We have also discontinued use of various C++ features in certain
> parts of the codebase (such as soi disant smart pointers) for performance reasons.
>
> Sure, we'll eventually move forward, but that's a long process, and in the
> mean time, pre-C++11 code is required.

You are doing it wrong (TM).

[Ian Collins]

Pity the poor sods who run windows sever 2003... As for Python 3, why
bother?

> We have also discontinued use of various C++ features in certain
> parts of the codebase (such as soi disant smart pointers) for performance reasons.

I still find your claims about smart pointers hard to believe, unless
you were doing some thing seriously wrong with them.

--
Ian.

[David Brown]

How about if you are absolutely certain that such code is rare, and not
your fault or your problem, and that neither you nor others reading your
code should suffer extra ugliness because of such rare code?

You can't protect against people being malicious or stupid. It can make
sense to take precautions against more likely accidental mistakes, but
this is not one of them. And the :: prefix to "std" will not help if
someone puts their own code in "std" - it would only help against
someone making a new nested namespace called "std". It is simply an
ugly way for some C++ programmers to make it look like they are smarter
than others, when they in fact are not.

[Vir Campestris]

On 19/01/2019 20:56, woodb...@gmail.com wrote:
> I've wondered
> if 2011 C++ is the new C.

You can't run any reasonable subset of C++ without an RTL.

I've run C bare metal. No RTL at all, and a few lines of assembler to
start it up.

Andy

[David Brown]

On 20/01/2019 22:30, Vir Campestris wrote:
> On 19/01/2019 20:56, woodb...@gmail.com wrote:
>> I've wondered
>> if 2011 C++ is the new C.
>
> You can't run any reasonable subset of C++ without an RTL.
>

Of course you can - depending on how you define "reasonable". Usually
on small or bare metal systems you disable exceptions and RTTI. You
might not be able to use the container libraries, algorithms, and some
of the other "higher level" libraries, but you can use a great deal just
fine.

> I've run C bare metal. No RTL at all, and a few lines of assembler to
> start it up.
>

I've done that too. I've even run C with no ram (to be fair, the
program was not very big!). But even cheap and tiny embedded systems
these days have enough flash and ram for some basic parts of the library.

[Ian Collins]

On 21/01/2019 10:30, Vir Campestris wrote:
> On 19/01/2019 20:56, woodb...@gmail.com wrote:
>> I've wondered
>> if 2011 C++ is the new C.
>
> You can't run any reasonable subset of C++ without an RTL.

Nonsense.

> I've run C bare metal. No RTL at all, and a few lines of assembler to
> start it up.

I've run C++ bare metal. No RTL at all, and a few lines of assembler to
start it up.

--
Ian

[fir]

W dniu sobota, 19 stycznia 2019 20:13:48 UTC+1 użytkownik Lynn McGuire napisał:
> "Is C++ fast?"

> https://www.osnews.com/story/129217/is-c-fast/
>
> "A library that I work on often these days, meshoptimizer, has changed
> over time to use fewer and fewer C++ library features, up until the
> current state where the code closely resembles C even though it uses

> some C++ features. There have been many reasons behind the changes –

> dropping C++11 requirement allowed me to make sure anybody can compile
> the library on any platform, removing std::vector substantially improved
> performance of unoptimized builds, removing algorithm includes sped up

> compilation. However, I’ve never quite taken the leap all the way to C
> with this codebase. Today we’ll explore the gamut of possible C++

> implementations for one specific algorithm, mesh simplifier, henceforth
> known as simplifier.cpp, and see if going all the way to C is worthwhile."

> https://zeuxcg.org/2019/01/17/is-c-fast/
>

the outcome and conclusion of this article is obious, (doeas realy somebody didnt know that?) : c++ has some subset that is same fast as c

eventually one thing interesting to see there was comparison of compile times and run times of initial c++ and final c-like c++ (compiles 3-4 times slower, runtimes 2 times slower)

this may be representative (though as to compile times it much depend on compiler, as afair they not muche optimized for speed and i guess both c and simple c++
could go much faster anyway)

[Juha Nieminen]

fir <profes...@gmail.com> wrote:
> the outcome and conclusion of this article is obious, (doeas realy
> somebody didnt know that?) : c++ has some subset that is same fast as c

Know your tools. Just because doing things in way X, which might eschew the
convenience of eg. the standard library, results in more efficient code, that
doesn't mean that *the entire program* has to be done in that way.

Use the hacker optimizations where they are needed. In less critical parts,
use what's best for the development and maintenance of the project.

There might be some really time-critical number-crunching sections of the
program where you want to engage in some really low-level optimization
(such as cache optimization), but that doesn't mean that the entire
million-lines-of-code program has to be done in the same way.

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[James Kuyper]

On 1/20/19 14:22, David Brown wrote:
> On 20/01/2019 17:30, James Kuyper wrote:
>> On 1/19/19 23:05, Ian Collins wrote:
>>> On 20/01/2019 16:59, woodb...@gmail.com wrote:
>>>> On Saturday, January 19, 2019 at 9:38:23 PM UTC-6, Ian Collins wrote:
>>>>> On 20/01/2019 16:31, woodb...@gmail.com wrote:
>> ...
>>>>>> Let me guess. You haven't adopted :: prefixes yet.
>>>>>
>>>>> Why would anyone adopt such a superfluous abomination?
>>>>>
>>>>> No sane programmer would either overload C standard library function
>>>>> names or introduce their own namespace std.
>>>>>
>>>>
>>>> Sure, but there are insane and/or malicious hackers out
>>>> there.
>>>
>>> So how does a :: prefixe solve that problem?
>>
>> Whenever you use such a prefix, you prevent yourself from accidentally
>> using a corresponding identifier defined by such programmers. Of course,
>> if you're absolutely certain that your code will never have to work with
>> code written by such people, then you don't need such prefixes.
>>
>
> How about if you are absolutely certain that such code is rare, and not
> your fault or your problem, and that neither you nor others reading your
> code should suffer extra ugliness because of such rare code?

If it's merely rare, rather than none-existent, you have to decide
whether suffering the ugliness or suffering the occasional hard-to-debug
error is worse. It's a judgment call, and as such, I can't fault a
decision EITHER way. But it is not something that should absolutely
obviously be chosen only one way.

> You can't protect against people being malicious or stupid. It can make
> sense to take precautions against more likely accidental mistakes, but
> this is not one of them. And the :: prefix to "std" will not help if

> someone puts their own code in "std" ...

But such code had undefined behavior, and seems trivially diagnosable to
me, so I would hope for some compiler protection against it.

> ... - it would only help against

> someone making a new nested namespace called "std".

That, on the other hand, has perfectly well-defined behavior - behavior
which might not be what you want if you ignore that possibility. At
most, a compiler can issue a warning - it's not allowed to reject such code.

[David Brown]

Agreed.

But has anyone ever seen code for which it could help? That would prove
that the problem is not non-existent.

>
>> You can't protect against people being malicious or stupid. It can make
>> sense to take precautions against more likely accidental mistakes, but
>> this is not one of them. And the :: prefix to "std" will not help if
>> someone puts their own code in "std" ...
>
> But such code had undefined behavior, and seems trivially diagnosable to
> me, so I would hope for some compiler protection against it.

Certainly compilers could help here.

However, while putting your own code in std:: is undefined behaviour,
that does not mean it is not sometimes useful. The situation is
analogous to making your own definitions of standard C library
functions. When done with due care and respect, for non-portable code,
it can be useful.

[Richard Damon]

On 1/21/19 10:34 AM, David Brown wrote:
> However, while putting your own code in std:: is undefined behaviour,
> that does not mean it is not sometimes useful. The situation is
> analogous to making your own definitions of standard C library
> functions. When done with due care and respect, for non-portable code,
> it can be useful.

One exception to this rule is for templates defined in the ::std
namespace. The programmer is allowed to add specializations for these
templates, as long as at least 1 of the template parameters is a user
defined type, and the definition meets the requirements for that
template. (20.5.4.2.1p1)

[Scott Lurndal]

Actually, you can. I've run C++ bare metal (two different bare
metal hypervisors and a massively parallel distributed Unix-like
microkernel based operating system), no RTL and a handful
of lines to support compiler generated symbols and a few lines of
assembler to start it up. A page based allocator and a generic
pool class suffices to support dynamic allocation (via overloaded
'new'/'delete'). Of course, no exceptions or RTTI.


//
// C++ Support functions
//

/*
* Symbols defined in the linker script to mark the ctor list.
*/
extern void (*__CTOR_LIST__[])();

#include "dvmm.h"
#include "util/support.h"

/*
* This is called by setup64.S to call the constructors of global objects,
* before it calls dvmm_bsp_start().
*
* GNU LD lays out the __CTOR_LIST__ as an array of function pointers. The
* first element of the array (index == 0) contains an integer which
* represents the value derived from subtracting two from the actual number
* of entries in the table. Thus the content of the first element is
* one less than the index of the last entry in the table.
*
* Call in reverse order XXX - why? Check crt0.o for canonical behavior
*/
extern "C" void
__call_constructors()
{
size_t count = *(size_t *)__CTOR_LIST__;

for(count++; count; --count) {
__CTOR_LIST__[count]();
}
}

/*
* G++'s generated code calls this if a pure virtual member is ever called.
*/
extern "C" void
__cxa_pure_virtual()
{
panic("pure virtual function called\n");
}

/*
* This is needed even though we don't ever use the delete operator because
* G++ generates an extra (unused) virtual destructor that calls it.
*/
void
operator delete(void *)
{
panic("operator delete(void*) called\n");
}

/*
* Catch unintended calls to new.
*/
void*
operator new(size_t)
{
panic("operator new(void*) called\n");
}


/*
* G++ generates code for shared library support, even though it isn't
* relevant (or called). That code looks for this symbol.
*/
void *__dso_handle;

/*
* Global object constructors call this to register their corresponding
* destructor. We just ignore it; we never call global object destructors
* because we never exit.
*/
extern "C" int
__cxa_atexit(void (*f)(void *), void *p, void *d)
{
return 0;
}

[fir]

interesting, as far as i remember i disasembled pure c codes from gcc and things like that also was showing in disasembly

(but maybe im wrong, it seems wrong like i compiled c code in c++ mode maybe.. now it seems clearer anyway)

where are the old limes whan you knew all sole byte in disasembly of your app?

[Mr Flibble]

On 21/01/2019 16:42, Scott Lurndal wrote:
> Vir Campestris <vir.cam...@invalid.invalid> writes:
>> On 19/01/2019 20:56, woodb...@gmail.com wrote:
>>> I've wondered
>>> if 2011 C++ is the new C.
>>
>> You can't run any reasonable subset of C++ without an RTL.
>
>>
>> I've run C bare metal. No RTL at all, and a few lines of assembler to
>> start it up.
>>
>> Andy
>
> Actually, you can. I've run C++ bare metal (two different bare
> metal hypervisors and a massively parallel distributed Unix-like
> microkernel based operating system), no RTL and a handful
> of lines to support compiler generated symbols and a few lines of
> assembler to start it up. A page based allocator and a generic
> pool class suffices to support dynamic allocation (via overloaded
> 'new'/'delete'). Of course, no exceptions or RTTI.

I don't see why supporting C++ exceptions in an OS kernel is too onerous,
or RTTI for that matter (but one should keep dynamic_cast to minimum but
that is a different story).

[Christian Gollwitzer]

Am 21.01.19 um 19:38 schrieb Mr Flibble:

> I don't see why supporting C++ exceptions in an OS kernel is too
> onerous, or RTTI for that matter (but one should keep dynamic_cast to
> minimum but that is a different story).

How do you handle stack unwinding, especially when the exception hits
the stack level where user code called into the kernel? The user code
also doesn't need to explicitly call the kernel, it could also be
interrupted by preemptive multitasking at any point.

Christian

[Mr Flibble]

I am not suggesting kernel exceptions would be exposed to userland; they
would be an internal implementation detail entirely. Stack unwinding
would hit a last chance try block which could panic (so stack unwinding is
not exposed to userland).

I admit I don't actually know what I am talking about as I have yet to
create an operating system as a hobby project -- so many other things to
do and life is too short and there aren't enough hours in a day. I am
reinventing enough wheels as it is.

[Scott Lurndal]

Mr Flibble <flibbleREM...@i42.co.uk> writes:
>On 21/01/2019 16:42, Scott Lurndal wrote:
>> Vir Campestris <vir.cam...@invalid.invalid> writes:

>>> You can't run any reasonable subset of C++ without an RTL.

[snip]

>> Of course, no exceptions or RTTI.
>
>I don't see why supporting C++ exceptions in an OS kernel is too onerous,
>or RTTI for that matter (but one should keep dynamic_cast to minimum but
>that is a different story).

Overhead. Every cycle used by an operating system can't be given to
an application doing useful work (and then there's the constant fight
to win the OS benchmark battle, e.g. TCP-H, et alia). Every instruction
matters in order to preserve the most icache entries for the application.

I've also worked with a user-level application (mainframe simulator) that
mapped simulated processor exceptions to siglongjmp (the code predated
C++ exceptions). After discussions here a few years ago, I created a
version of it that used exceptions instead of sigsetjmp/siglongjmp. Lost
about 10% in performance, so those changes were discarded. Note that
both this application is completely cpu bound, so every cycle matters.

[Josef Moellers]

On 21.01.19 19:38, Mr Flibble wrote:
> On 21/01/2019 16:42, Scott Lurndal wrote:
>> Vir Campestris <vir.cam...@invalid.invalid> writes:
>>> On 19/01/2019 20:56, woodb...@gmail.com wrote:
>>>> I've wondered
>>>> if 2011 C++ is the new C.
>>>
>>> You can't run any reasonable subset of C++ without an RTL.
>>
>>>
>>> I've run C bare metal. No RTL at all, and a few lines of assembler to
>>> start it up.
>>>
>>> Andy
>>
>> Actually, you can.   I've run C++ bare metal (two different bare
>> metal hypervisors and a massively parallel distributed Unix-like
>> microkernel based operating system), no RTL and a handful
>> of lines to support compiler generated symbols and a few lines of
>> assembler to start it up.  A page based allocator and a generic
>> pool class suffices to support dynamic allocation (via overloaded
>> 'new'/'delete').  Of course, no exceptions or RTTI.
>
> I don't see why supporting C++ exceptions in an OS kernel is too
> onerous, or RTTI for that matter (but one should keep dynamic_cast to
> minimum but that is a different story).

Because if it can be done in user land it should be done in user land.

Of course, if you have a special system which only has C++, things are
different: you would put lots of things into the kernel which allows
sharing between applications, but in general this is a bad idea.

Josef

[bitrex]

On 01/19/2019 10:26 PM, Robert Wessel wrote:
> On Sat, 19 Jan 2019 15:36:09 -0800, "Chris M. Thomasson"
> <ahh_...@crap.nothing> wrote:
>
>> On 1/19/2019 2:57 PM, Ian Collins wrote:
>>> On 20/01/2019 11:49, David Brown wrote:
>>>> On 19/01/2019 22:35, Ian Collins wrote:
>>>>> On 20/01/2019 09:56, woodb...@gmail.com wrote:

>>>>>> On Saturday, January 19, 2019 at 1:18:36 PM UTC-6, Mr Flibble wrote:
>>>>
>>>>>>> Who cares about the performance of unoptimized builds?
>>>>>>

>>>>>> I do.
>>>>>
>>>>> Why?
>>>>
>>>> For the same reason people care how fast their car can go in first gear.
>>>
>>> That's a useful number - especially if it can get from 0 to 60 without
>>> changing up :)
>>>
>>
>> 0 to 60 in first gear: Exotic cars are nice!
>>
>> http://newmotoring.com/what-cars-will-do-60mph-in-first-gear
>
>
> Oddly they didn't include the Tesla S. Admittedly it one has only one
> gear, but it'll get well past sixty in that one. A base model 2012 S
> could do 0-60 in 5.9s. By 2015 (and the article is from 2016), you
> could get a 2.6s 0-60 in your S with the "Ludicrous Mode" option.
>

My 2017 Chevy Volt does 0-60 in just about 7 seconds which feels pretty
fast for a family sedan. 2.2 seconds for 0-30 which is a smidge faster
than a base trimline Model S from the same time.

The final sale price including cap cost reduction/tax incentive was
$26,000 as compared to whatever a Model S cost two years ago

[Vir Campestris]

On 21/01/2019 16:42, Scott Lurndal wrote:

> Actually, you can. I've run C++ bare metal (two different bare
> metal hypervisors and a massively parallel distributed Unix-like
> microkernel based operating system), no RTL and a handful
> of lines to support compiler generated symbols and a few lines of
> assembler to start it up. A page based allocator and a generic
> pool class suffices to support dynamic allocation (via overloaded
> 'new'/'delete'). Of course, no exceptions or RTTI.

I appear to be outvoted (pace Ian & David)!

I think we're down to the semantics of what you call a reasonable subset.

IMHO by the time you've excluded STL, exceptions & RTTI it's a pretty
small subset.

I think we'll beg to differ.

And running without RAM? I only did it once. In assembler - using the
registers for memory. Calling functions is interesting... but I wanted a
way to report that there was no good RAM in the machine during POST.

Andy

[David Brown]

On 22/01/2019 22:46, Vir Campestris wrote:
> On 21/01/2019 16:42, Scott Lurndal wrote:
>> Actually, you can.   I've run C++ bare metal (two different bare
>> metal hypervisors and a massively parallel distributed Unix-like
>> microkernel based operating system), no RTL and a handful
>> of lines to support compiler generated symbols and a few lines of
>> assembler to start it up.  A page based allocator and a generic
>> pool class suffices to support dynamic allocation (via overloaded
>> 'new'/'delete').  Of course, no exceptions or RTTI.
>
> I appear to be outvoted (pace Ian & David)!
>
> I think we're down to the semantics of what you call a reasonable subset.

If you are using a C++ compiler, writing code in a way that could not
conveniently be translated to C, then you are using a "reasonable
subset" of C++. Would that do as a definition?

>
> IMHO by the time you've excluded STL, exceptions & RTTI it's a pretty
> small subset.

Not really, no. RTTI is quite a minor feature for most C++ code - it's
not needed for virtual functions or most exceptions. Exceptions are
avoided by some coding standards (such as Google's) even when resources
are abundant. And we are not talking about excluding the whole standard
library - merely some part of it (such as most containers).

>
> I think we'll beg to differ.
>
> And running without RAM? I only did it once. In assembler - using the
> registers for memory. Calling functions is interesting... but I wanted a
> way to report that there was no good RAM in the machine during POST.
>

This was on an AVR Tiny - an 8-bit cpu with 32 8-bit registers, no RAM,
and (IIRC) 2K of program flash. It had a three entry hardware stack for
function calls. There were a few tricks involved, as you might expect,
but it all worked using the standard AVR port of gcc. As I say, it was
a really simple program, however.

[Richard]

[Please do not mail me a copy of your followup]

Ian Collins <ian-...@hotmail.com> spake the secret code
<gajubn...@mid.individual.net> thusly:

>I still find your claims about smart pointers hard to believe, unless
>you were doing some thing seriously wrong with them.

I don't know about the other poster, but I worked on a code base where
data members were held in smart pointers, boost::shared_ptr<T> to be
exact, or returned from functions as smart pointers, and the smart
pointer would be passed by value down a long chain of function calls.

IMO, this was a stupid mistake. You spend all your time incrementing
and decrementing reference counts on this smart pointer as it gets
passed by value up and down the call chain for no good reason.

You should only pass the smart pointer when someone needs to hold onto
the shared_ptr. Otherwise, just pass the raw pointer (or better yet, a
reference) up and down the call chain. The C++ guidelines being created
by Sutter, Stroustrup, et al., have special zero-overhead template types
that indicate that the raw pointer is only to be consumed and does not
indicate a transfer of ownership. I like that idea -- use templates as
executable documentation on the meaning of a raw pointer.

Perhaps it is this sort of mindless use of smart pointers that caused
the other poster to banish smart pointers from their code base. IMO,
that is throwing the baby out with the bath water, but it's their
code, let them code it the way they want.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Richard]

[Please do not mail me a copy of your followup]

Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
<q22p9b$g64$2...@dont-email.me> thusly:

>On 19/01/2019 20:56, woodb...@gmail.com wrote:
>> I've wondered
>> if 2011 C++ is the new C.
>
>You can't run any reasonable subset of C++ without an RTL.

Bollocks. GBA demo hackers do it all the time.

Look at Michael Caisse's videos over the past few years.
Look at Kvasir.

[Jorgen Grahn]

On Tue, 2019-01-22, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Ian Collins <ian-...@hotmail.com> spake the secret code
> <gajubn...@mid.individual.net> thusly:
>
>>I still find your claims about smart pointers hard to believe, unless
>>you were doing some thing seriously wrong with them.
>
> I don't know about the other poster, but I worked on a code base where
> data members were held in smart pointers, boost::shared_ptr<T> to be
> exact, or returned from functions as smart pointers, and the smart
> pointer would be passed by value down a long chain of function calls.

Me too. Perhaps it's a Java or C# influence.

> IMO, this was a stupid mistake.

Yes -- and surprisingly hard to do something about once the whole code
base is like that. If everyone has shared_ptrs to A, A has to have
shared_ptrs to everyone else, because is lifetime is unknown.

(Which, like you say, doesn't mean all uses smart pointers are
stupid.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Manfred]

This is one reason for which I use unique_ptr's a lot, but I am very
careful with shared_ptr's.

>
> /Jorgen
>

[Daniel]

On Wednesday, January 23, 2019 at 8:59:11 AM UTC-5, Jorgen Grahn wrote:
> On Tue, 2019-01-22, Richard wrote:
> > I don't know about the other poster, but I worked on a code base where
> > data members were held in smart pointers, boost::shared_ptr<T> to be
> > exact, or returned from functions as smart pointers, and the smart
> > pointer would be passed by value down a long chain of function calls.
>

> Perhaps it's a Java or C# influence.
>

Indeed, references in Java and C# eliminate entire categories of performance
challenges that C++ has struggled with (no need for move!), but it's not
ideal to take the same approaches in a language where all you have is
reference counted pointers.

Daniel

[Richard]

[Please do not mail me a copy of your followup]

Daniel <daniel...@gmail.com> spake the secret code
<65429a21-7ade-4ee7...@googlegroups.com> thusly:

>On Wednesday, January 23, 2019 at 8:59:11 AM UTC-5, Jorgen Grahn wrote:
>> On Tue, 2019-01-22, Richard wrote:
>> > I don't know about the other poster, but I worked on a code base where
>> > data members were held in smart pointers, boost::shared_ptr<T> to be
>> > exact, or returned from functions as smart pointers, and the smart
>> > pointer would be passed by value down a long chain of function calls.
>>
>> Perhaps it's a Java or C# influence.
>>
>Indeed, references in Java and C# eliminate entire categories of performance

>challenges that C++ has struggled with [...]

It isn't a question of a "performance challenge", it's as Jorgen said
a C#/Java mentality.

You can always write non-performance code if you do something stupid.

[Daniel]

On Wednesday, January 23, 2019 at 1:03:43 PM UTC-5, Richard wrote:
> [Please do not mail me a copy of your followup]
>

> Daniel spake the secret code
> <65429a21-7ade-4ee7...@googlegroups.com> thusly:
> >>

> >Indeed, references in Java and C# eliminate entire categories of performance
> >challenges that C++ has struggled with [...]
>
> It isn't a question of a "performance challenge", it's as Jorgen said
> a C#/Java mentality.
>

Totally agree, C#/Java make simple what in c++ takes more work.

Best regards,
Daniel

[Jux und Tollerei]

C++ is about as fast as Java with a decent JIT-compiler.

[Stuart Redmann]

I wouldn't say "takes more work" but rather is easier to get wrong or
inefficient.

As a general guideline, one should use plain pointers in function calls, if
the called function does not need to know about ownership of the pointer.
That adds zero overhead to the calling code, but requires you to know when
to use smart pointers as parameters and when to use plain pointers. IOW,
you can code just as efficiently and effortlessly as in Java but you have
to know what you are doing.

Most of the time you would not even use pointers as parameters but rather
const references. If I had to mimic const-reference-parameters in Java, I
would have to write tons of code. Java code is usually littered with checks
that parameters are not null. These checks are usually not needed in C++,
so "proper" Java code is inherently slower than C++ code, even if Java is
executed as native code.

Regards,
Stuart

[Öö Tiib]

On Thursday, 24 January 2019 10:21:48 UTC+2, Jux und Tollerei wrote:
> C++ is about as fast as Java with a decent JIT-compiler.

Controversial topic.

1) Pure C++ and Java in expert hands and compiled and
ran with most decent stuff there is then C++ runs algorithms
about twice faster, C++ takes about twice less power and the memory
usage is about 6 times smaller. Python has twice smaller memory
usage than Java but is also way slower and more energy
consuming than Java.

2) Experts are limited and expensive resource. Most of code is
written by mediocres or worse. If to compare languages in hands
of beginners then picture is reversed and C++ is usually doing worst.
It is harder to damage efficiency with Python.

3) We do not have pure things in actual reality. Most working
systems are hybrids where custom code written by less experienced
programmers forwards most heavy lifting to C or C++ libraries and
modules (that are written by more experienced programmers). There
the efficiency differences of 1) do not manifest but noob factor of 2)
takes its toll.

[Jux und Tollerei]

> 1) Pure C++ and Java in expert hands and compiled and
> ran with most decent stuff there is then C++ runs algorithms
> about twice faster, C++ takes about twice less power and the memory
> usage is about 6 times smaller. Python has twice smaller memory
> usage than Java but is also way slower and more energy
> consuming than Java.

That's your *opinion*, which is affected by your taste.
Java can be even faster than C++ in most cases because of its
dynamic compilation.

[leigh.v....@googlemail.com]

False. Also, most JVMs are written in C++.

/Leigh

[David Brown]

No, it cannot.

There /are/ situations where dynamic compilation can result in faster
code than static compilation. I've seen examples of PyPy being faster
than equivalent C code when using generic algorithms - JIT compilation
can make specialised versions of functions for each type used, while the
C code would use generic functions like "memcpy" and indirect comparison
functions. But with C++, the equivalent code would be template based
and these specialisations would be sorted out at compile time. This
will beat JIT every time.

The only other way I know of for JIT to beat static compilation, other
than forgetting to enable optimisation, would be if the static
compilation were done for a very generic member of the processor family
while the JIT tuned for specific features (like SIMD instructions).
However, I would not expect Java with JIT to come close to tuned C++
code compiled for the specific target features. And compilers like gcc
let you (relatively) easily make multiple copies of critical functions,
picking the best one at run-time for the processor you happen to use.

Of course, in any given project there are many other things to take into
account when talking about speed. Speed of development, time to market,
speed of code for a given development budget, etc. You can often get a
great deal more speed for your money using Python and PyPy (JIT) than
Java or C++ - there is no single right answer to "fastest programming
language". But the idea that dynamic compilation is faster than static
compilation is, for the most part, wrong.

[Bonita Montero]

>> That's your *opinion*, which is affected by your taste.
>> Java can be even faster than C++ in most cases because of its
>> dynamic compilation.

> False. Also, most JVMs are written in C++.

You can write a compiler in a scripting-language which
ist significantly slower than the compiled code.

[Bonita Montero]

No, JITs are faster in most cases.

[Jux und Tollerei]

> Shootoutgames has done so and shown Java to be
> slower by a factor of two.

That depends on the skill of the Java-programmer.

[Öö Tiib]

On Thursday, 24 January 2019 11:47:19 UTC+2, Jux und Tollerei wrote:
> > 1) Pure C++ and Java in expert hands and compiled and
> > ran with most decent stuff there is then C++ runs algorithms
> > about twice faster, C++ takes about twice less power and the memory
> > usage is about 6 times smaller. Python has twice smaller memory
> > usage than Java but is also way slower and more energy
> > consuming than Java.
>
> That's your *opinion*, which is affected by your taste.

No. It is opinion of researchers.
https://sites.google.com/view/energy-efficiency-languages/results?authuser=0

> Java can be even faster than C++ in most cases because of its
> dynamic compilation.

I agreed (but you snipped) that it is so in idiots hands.
Perhaps your personal experience is talking.

[Öö Tiib]

Why only the weak Java programmers enter competitions so best
is twice worse than best C++ competitor?

[Jux und Tollerei]

> No. It is opinion of researchers.

> https://sites.google.com/...

Yes, the *opinion*, not the fact!

[Jux und Tollerei]

>> That depends on the skill of the Java-programmer.

> Why only the weak Java programmers enter competitions so best
> is twice worse than best C++ competitor?

I don't know, but skilled programmers get more performance out of
a JVM than with native languages in most cases.

[Scott Lurndal]

Proof by assertion isn't sufficient. Show your work - provide citations
for the studies that prove your assertion.

[Öö Tiib]

Why you reiterate your bald unsubstantiated assertions?
Canät give any cites? Are you religious Java fundamentalist?

Those indeed can't win any competitions because they are
dumb. Only thing that is sure that they get more performance out of
JVM than from anything else. They worship it. Sad, but somehow
makes me laugh. :D

https://sites.google.com/view/energy-efficiency-languages/results?authuser=0

[Öö Tiib]

Look it again these were tables of facts
https://sites.google.com/view/energy-efficiency-languages/results?authuser=0

[Jux und Tollerei]

> Why you reiterate your bald unsubstantiated assertions?
> Canät give any cites? Are you religious Java fundamentalist?
>
> Those indeed can't win any competitions because they are
> dumb. Only thing that is sure that they get more performance out of
> JVM than from anything else. They worship it. Sad, but somehow
> makes me laugh. :D
>
> https://sites.google.com/view/energy-efficiency-languages/results?authuser=0

Consider this analogy: when you spend more energy in something,
you are faster.

[Jux und Tollerei]

>> Yes, the *opinion*, not the fact!

> Look it again these were tables of facts
> https://sites.google.com/view/energy-efficiency-languages/results?authuser=0

This is about energy-efficiency, not speed.

[Christian Gollwitzer]

Am 24.01.19 um 14:53 schrieb Öö Tiib:

> On Thursday, 24 January 2019 13:21:42 UTC+2, Jux und Tollerei wrote:
>>>> That depends on the skill of the Java-programmer.
>>
>>> Why only the weak Java programmers enter competitions so best
>>> is twice worse than best C++ competitor?
>>
>> I don't know, but skilled programmers get more performance out of
>> a JVM than with native languages in most cases.
>
> Why you reiterate your bald unsubstantiated assertions?

Because he is an obvious troll. Even the nickname ("Jux und Tollerei" =
German for "Just for fun") tells this.

Christian

[Öö Tiib]

When you spend more energy on something then you are less efficient.
Look at those tables again, (and cry, :D) time was also given there.

[Öö Tiib]

Look again, all of speed, energy and memory usage was measured.

[Öö Tiib]

I enjoy his trolling. At least it is more on topic than Rick's sad story of
fruitless messenger of Creator.

[Jux und Tollerei]

>> Consider this analogy: when you spend more energy in something,
>> you are faster.

> When you spend more energy on something then you are less efficient.
> Look at those tables again, (and cry, :D) time was also given there.

Speed rules over efficiency.

[Jux und Tollerei]

>>> Look it again these were tables of facts
>>> https://sites.google.com/view/energy-efficiency-languages/results?authuser=0

>> This is about energy-efficiency, not speed.

> Look again, all of speed, energy and memory usage was measured.

Then they obviously made a major mistake.
It is a physical principe, that when you make more effort,
i.e. get less efficiency, you get a higher performance.

[Manfred]

Or: in IT (i.e. Information Technology in case he doesn't recall), more
energy typically means more CPU cycles, i.e. slower computing.

(More sobbing echoes..)

[Daniel]

On Thursday, January 24, 2019 at 4:35:57 AM UTC-5, Stuart Redmann wrote:

> Daniel wrote:

> > C#/Java make simple what in c++ takes more work.
> >

> I wouldn't say "takes more work" but rather is easier to get wrong or
> inefficient.
>
> As a general guideline, one should use plain pointers in function calls, if
> the called function does not need to know about ownership of the pointer.
> That adds zero overhead to the calling code, but requires you to know when
> to use smart pointers as parameters and when to use plain pointers. IOW,
> you can code just as efficiently and effortlessly as in Java but you have
> to know what you are doing.
>
> Most of the time you would not even use pointers as parameters but rather
> const references. If I had to mimic const-reference-parameters in Java, I
> would have to write tons of code. Java code is usually littered with checks
> that parameters are not null. These checks are usually not needed in C++,
> so "proper" Java code is inherently slower than C++ code, even if Java is
> executed as native code.
>

Appreciate the balanced comments.

Generally speaking I prefer the reference + gc model in java/c# and most
(all?) newer languages to the C++ model. It's simpler, cleaner and more
consistent. And in principle it avoids the need for copies, which is safe as
long as java/c# programmers use immutable interfaces as consistently as C++
programmers use const. Unfortunately this isn't always the case, the library
containers don't come with immutable interfaces, and it's not unusual for a
C# programmers to make a copy after calling a function because they don't
trust what that function might have done with their reference.

Daniel

[Öö Tiib]

There are no such laws of physics. Resources can be
(and are often) burned without any benefits in this universe.
Java is bit simpler to use and more difficult to misuse than
C++ and that is paid with inefficiency. So it has benefits,
but it is not speed.

[Jux und Tollerei]

> There are no such laws of physics. Resources can be
> (and are often) burned without any benefits in this universe.
> Java is bit simpler to use and more difficult to misuse than
> C++ and that is paid with inefficiency. So it has benefits,
> but it is not speed.

You're wrong because you're not skilled enough to write performant
Java-code.

[leigh.v....@googlemail.com]

I disagree with your assertion that Java is simpler than C++ to use. C++ is more complex than Java sure but it doesn't follow that that makes Java easier to use: the complexity of the C++ language and library implementation actually pulls complexity out of the C++ programs you write. The simplest programming language of all is arguably assembly but try writing anything non-trivial in assembly.

/Leigh

[Öö Tiib]

I like the idea (started by D language) that fundamental types and structs
are (by default) passed by value and classes are (by default) passed by
reference. This leaves the opportunity to control it in but removes the need
to type it out.
I think Swift has made that, immutability control and if something is optional
or not (can be null or not) close to perfectly.
All of it is still under my control but i don't have to type piles of "const&"
or null checking garbage for that, it does the right thing by default and
complains when I forget something about it.

[Daniel]

On Thursday, January 24, 2019 at 4:37:30 AM UTC-5, Öö Tiib wrote:
> On Thursday, 24 January 2019 10:21:48 UTC+2, Jux und Tollerei wrote:
> > C++ is about as fast as Java with a decent JIT-compiler.
>
> Controversial topic.

>
> 1) Pure C++ and Java in expert hands and compiled and
> ran with most decent stuff there is then C++ runs algorithms
> about twice faster, C++ takes about twice less power and the memory
> usage is about 6 times smaller.
>

Possibly of relevance:

http://www.vldb.org/pvldb/vol10/p1118-li.pdf

In this paper, the author finds that the Java-based JSON libraries (GSON and
Jackson) are often faster than RapidJSON, which is written in C++, and what I
would regard as the fastest open source C++ json library that is safe for
general use. On the other hand, the author's own, faster, attempt is written
in C++, and employs SIMD vectorization and "bitwise parallelism". So perhaps
we can conclude that skilled programmers writing a classic FSM C++ json
parser, and squeezing out all the performance they can by avoiding the C++
and C library functions for string/number conversions and supplying their own
(as RapidJson does), can only get close to the Java implementations, but that
C++ can provide opportunities for new and faster techniques :-)

> 2) Experts are limited and expensive resource. Most of code is
> written by mediocres or worse.
>
Just so :-)

[Cholo Lennon]

Wow... how about you? show us your Java credentials please.


--
Cholo Lennon
Bs.As.
ARG

[Bonita Montero]

>> You're wrong because you're not skilled enough to write performant
>> Java-code.

> Wow... how about you? show us your Java credentials please.

I'm using Java on HPC-systems since the beginning of the first JIT-VM.

[Daniel]

On Thursday, January 24, 2019 at 11:19:32 AM UTC-5, Öö Tiib wrote:
>
> I like the idea (started by D language) that fundamental types and structs
> are (by default) passed by value and classes are (by default) passed by
> reference. This leaves the opportunity to control it in but removes the need
> to type it out.
> I think Swift has made that, immutability control and if something is optional
> or not (can be null or not) close to perfectly.
> All of it is still under my control but i don't have to type piles of "const&"
> or null checking garbage for that, it does the right thing by default and
> complains when I forget something about it.

C# has a similar distinction between struct and class.

Do you think D still has a chance to break through? It's been around for a
long time.

Daniel

[Thiago Adams]

The first edition of C did it right.

From the C programming language first edition:

"There are a number of restrictions on C structures. The essential rules
are that the only operations that you can perform on a structure are take its
address with c, and access one of its members. This implies that structures
may not be assigned to or copied as a unit, and that they can not be passed
to or returned from functions. (These restrictions will be removed in forthcoming versions.) Pointers to structures do not suffer these limitations,
however, so structures and functions do work together comfortably.
"

In other words struct had to be passed as pointer and it was the only
way.
In 2019, I think 100% of my code don't passes structs by value.

I use struct assignment and I think returning structs can be useful
for initialization.

Since the begging C had the -> operator instead of just . (dot)

I would like to try a modified version of C passing structs as pointers
and without the -> operator. Arrays are already like that.

[Chris Vine]

Java is a horrible language to write code in. It's like being locked
in an Austin Powers movie, with its massive inheritance heirarchies and
1990's style OO.

However the JVM is quite nice and is perfectly usable if you use some
other language with it such as scala, clojure or kawa: I'm told that
kotlin is also good although I don't know much about it. You can have
particular cases where java/jvm is faster than c++ but they are
uncommon. There is a reason why rust follows the C++ approach to native
code generation.

However, the OP has the name "Jux und Tollerie". That should tell you
all you know that he is having gentle amusement at others expense. That
is, he is a relatively inoffensive troll.

[Chris Vine]

On Thu, 24 Jan 2019 19:11:48 +0000
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> However, the OP has the name "Jux und Tollerie". That should tell you
> all you know that he is having gentle amusement at others expense. That
> is, he is a relatively inoffensive troll.

Ah, I see that someone else has pointed that out further down the thread.

[Daniel]

On Thursday, January 24, 2019 at 2:12:06 PM UTC-5, Chris Vine wrote:
>
> Java is a horrible language to write code in.

This is of course an opinion with comparable intellectual heft to some of
the other opinions expressed herein :-) It's not, as I'm sure you realize, a
universally held opinion. During the nineties, Java largely replaced C++ as
the language in which middleware tooling and messaging software such as
TIBCO Business Works and IBM Process Server were written. Huge swathes of
software once written in C++, including financial trading systems and
computationally intensive risk systems, moved to JAVA, and later C#. There
were reasons for this. Do you understand why?

Daniel

[Mr Flibble]

Because of idiots such as yourself pushing Java due to not getting C++.
Also, C++ is a much better language now than it was in the 90s; there
wasn't even a C++ standard until 1998.

/Flibble

--
“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” –
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."

[Chris Vine]

It looks as if you do, but that was not my point.

On your (not my) point, garbage collection and automatic memory
management probably had a lot to do with. Not everyone wants the
fastest code; fast enough with memory safety may be ... enough[1]. As
far as being a horrible language is concerned, Java is a product of its
time and the OOP craze, which it has locked itself into in a way which
C++ has not needed to. And you don't have to write java code to use the
JVM.

What's your version of an answer to your question?

Anyway the future of java and those using it will be determined by
Oracle, who have decided that they will monetize java through the
GPL2+CE. We will see how that goes for them.

[1] Rust with its linear/affine type system has obtained memory safety
without garbage collection. In practice C++ has largely ameliorated
memory management issues if you stick to the correct C++ (as opposed to
C) idioms for writing good code.

[Daniel]

On Thursday, January 24, 2019 at 3:48:27 PM UTC-5, Mr Flibble wrote:

> Because of idiots such as yourself pushing Java due to not getting C++.

"idiots such as myself not getting C++", well, as the author of an open
source C++ library that has thousands of users,
https://github.com/danielaparker/jsoncons, I don't think I'm entirely
not getting C++. But I'm sure that you have a reason for your opinion.

> Also, C++ is a much better language now than it was in the 90s; there
> wasn't even a C++ standard until 1998.
>

But it still doesn't have big integer, big decimal, and much much else :-) Up to now it hasn't had a fast way to convert a floating point number into a string with smallest decimal digits representation, although some hope is held out for "to_chars". It doesn't have the practical things that much software development needs. So people use other languages that have these things, even if many of the things are C code with bindings.

Daniel

[Mr Flibble]

On 24/01/2019 21:16, Daniel wrote:
> On Thursday, January 24, 2019 at 3:48:27 PM UTC-5, Mr Flibble wrote:
>
>> Because of idiots such as yourself pushing Java due to not getting C++.
>
> "idiots such as myself not getting C++", well, as the author of an open
> source C++ library that has thousands of users,
> https://github.com/danielaparker/jsoncons, I don't think I'm entirely
> not getting C++. But I'm sure that you have a reason for your opinion.

I wouldn't get all puffed up about your C++ JSON library. My C++ JSON
library "NoFussJSON" is 5.5x faster than yours at parsing according to
timings on https://github.com/miloyip/nativejson-benchmark (although I
have not yet submitted it to that benchmark project I ran their tests).

>
>> Also, C++ is a much better language now than it was in the 90s; there
>> wasn't even a C++ standard until 1998.
>>
> But it still doesn't have big integer, big decimal, and much much else :-) Up to now it hasn't had a fast way to convert a floating point number into a string with smallest decimal digits representation, although some hope is held out for "to_chars". It doesn't have the practical things that much software development needs. So people use other languages that have these things, even if many of the things are C code with bindings.

I disagree. Plenty of C++ libraries to choose from for such things.

[Vir Campestris]

On 24/01/2019 21:16, Daniel wrote:

> But it still doesn't have big integer, big decimal, and much much else:-) Up to now it hasn't had a fast way to convert a floating point number into a string with smallest decimal digits representation, although some hope is held out for "to_chars". It doesn't have the practical things that much software development needs. So people use other languages that have these things, even if many of the things are C code with bindings.

I don't recall the last time I had to handle big numbers. I suspect
that's true of most people.

But if you want one...

<https://en.wikipedia.org/wiki/List_of_C%2B%2B_multiple_precision_arithmetic_libraries>

AKA

http://tinyurl.com/ouavgzt

C++ is easily extensible for things like this.

Andy

[Daniel]

On Thursday, January 24, 2019 at 4:16:59 PM UTC-5, Chris Vine wrote:
>
> On your (not my) point, garbage collection and automatic memory
> management probably had a lot to do with. Not everyone wants the
> fastest code; fast enough with memory safety may be ... enough[1]. As
> far as being a horrible language is concerned, Java is a product of its
> time and the OOP craze, which it has locked itself into in a way which
> C++ has not needed to.
>

> What's your version of an answer to your question?

JAVA has become a distant memory to me, since it's many years since I've
done JAVA development. But here's some.

One, the simplicity and consistency of the reference+gc model. No need for std::move or std::forward :-).

Two, all the utilities, utilities for XML transformation, reading EBCDIC (all the variants of EBCDIC) or hundreds of other encodings, a very well designed IO library with distinction between byte reader/writers and character reader/writers, big decimal, big integer, a database API and much else. All the pieces needed for building things, under one roof.

Three, support for concurrency, especially the concurrency utilities that
Doug Lea introduced when he chaired JSR 166. Lea was very good.

Four, introspection. This was huge. It allowed binding between data and JAVA objects. In C++ JSON libraries, for example, there is a lot of emphasis on variant like types that hold unpacked JSON text. To the extent that the C++ libraries support binding to C++ types, users are generally required to extend traits classes that relate the user type to the variant type, or override decode/encode functions that transform one to the other. In JAVA you wouldn't see an analogous variant like type, you would have the data, some mappings (likely defaulting to name on name), and your object. Introspection allowed automation of data transformation.

>
> Anyway the future of java and those using it will be determined by
> Oracle, who have decided that they will monetize java through the
> GPL2+CE. We will see how that goes for them.
>

A lot of the positive feelings that JAVA had inspired vanished with Oracle's
acquisition of JAVA. I've haven't followed subsequent developments.

Daniel

[Chris Vine]

On Thu, 24 Jan 2019 14:09:25 -0800 (PST)
Daniel <daniel...@gmail.com> wrote:
> Three, support for concurrency, especially the concurrency utilities that
> Doug Lea introduced when he chaired JSR 166. Lea was very good.

Really? I think Java has lost out on this. Its concurrency story is
based on OS threads which I will agree it has squeezed the most out of:
however although it is good for cpu-bound workloads it is not so much
for other things. C# has await semantics which deal with concurrency
for you safely in a structured form[1]. Rust has built thread safety
into its type system. C++ will shortly have concurrency through
coroutines, which will work well with i/o-bound workloads (and is
already in the coroutines TS).

[1] Possibly java has this now but I don't think so. And lest you
think I have something against garbage collection, I absolutely don't.
I write more garbage collected code than I do C++, and as an aside I
have considerable respect for microsoft's language initiatives, but a
shame that F# was somewhat underwhelming.

[Daniel]

On Thursday, January 24, 2019 at 4:33:22 PM UTC-5, Mr Flibble wrote:
>
> I wouldn't get all puffed up

Not too puffed up :-) but it's found a niche, it attracts especially users
that need json/csv transformation, that need JSONPath, and more recently,
that need JSON/CBOR, as it currently has support for more CBOR types than
the others (byte string, bignum, big decimal, and some others.) As you know,
there are lots of tools in this space, the supply of free software vastly
exceeds the demand, as I'm sure you're finding out. I spend way too much time on this stuff, and it's obvious that others do too.

> My C++ JSON
> library "NoFussJSON" is 5.5x faster than yours at parsing according to
> timings on https://github.com/miloyip/nativejson-benchmark

Those are old benchmarks. Is your implementation standalone, or is it
bundled with something else? If standalone, I may add it to the parsers I
benchmark, to see how different approaches compare. These are my tests:

https://github.com/danielaparker/json_benchmarks/blob/master/report/performance.md

https://github.com/danielaparker/json_benchmarks/blob/master/report/performance_fp.md

https://danielaparker.github.io/json_benchmarks/

I prefer larger input files than Milo, and also prefer to separate tests
with floating point numbers and without. Performance tests with floating point numbers tend to be dominated by implementation choices for string-float conversion, and hide other aspects of architectural choices.

> (although I
> have not yet submitted it to that benchmark project I ran their tests).
>

I never did either, Milo took a couple of older versions of mine, which are
the ones in the benchmark.

Daniel

[Daniel]

On Thursday, January 24, 2019 at 4:37:57 PM UTC-5, Vir Campestris wrote:
>
> I don't recall the last time I had to handle big numbers.

The last time I _needed_ one was in 1999, when a colleague and I were
implementing a quasi random number generator using sobol sequences. There
wasn't much to go on then, and we started with a very basic implementation
in Numerical Recipes with low dimensionality, and very quickly discovered
that standard integers overflowed with anything more. I dusted it off recently, and am currently using that old implementation to convert CBOR
bignums to strings and back.

>
> But if you want one...
>
> <https://en.wikipedia.org/wiki/List_of_C%2B%2B_multiple_precision_arithmetic_libraries>
>

You're missing the point. It's not that you or I might have a need for a
bignum in a particular application. It's that the design of API's need
standard types. A database API (or a CBOR API) should have standard big
decimal, big integer and date time types to map between the things in the
database (or the CBOR packed bytes) and the things in the programming
language. JAVA has those, C# has those. If the language doesn't support
those things, good standard API's can't be written. At best they can bind to
a string, and leave it to application developers to convert that to their
preferred types.

Daniel

[Mr Flibble]

On 24/01/2019 22:45, Daniel wrote:
> On Thursday, January 24, 2019 at 4:33:22 PM UTC-5, Mr Flibble wrote:
>> My C++ JSON
>> library "NoFussJSON" is 5.5x faster than yours at parsing according to
>> timings on https://github.com/miloyip/nativejson-benchmark
>
> Those are old benchmarks. Is your implementation standalone, or is it
> bundled with something else? If standalone, I may add it to the parsers I
> benchmark, to see how different approaches compare. These are my tests:

It isn't standalone; it is part of my C++ utility library "neolib":

https://github.com/i42output/neolib/blob/master/include/neolib/json.hpp

[Daniel]

On Thursday, January 24, 2019 at 6:05:37 PM UTC-5, Mr Flibble wrote:
>
> It isn't standalone; it is part of my C++ utility library "neolib":
>
> https://github.com/i42output/neolib/blob/master/include/neolib/json.hpp
>

Fair enough.

Daniel

[Daniel]

On Thursday, January 24, 2019 at 5:36:34 PM UTC-5, Chris Vine wrote:
> On Thu, 24 Jan 2019 14:09:25 -0800 (PST)
> Daniel wrote:
> > Three, support for concurrency, especially the concurrency utilities that
> > Doug Lea introduced when he chaired JSR 166. Lea was very good.
>
> Really? I think Java has lost out on this. Its concurrency story is
> based on OS threads which I will agree it has squeezed the most out of:
> however although it is good for cpu-bound workloads it is not so much
> for other things. C# has await semantics which deal with concurrency
> for you safely in a structured form[1]. Rust has built thread safety
> into its type system. C++ will shortly have concurrency through
> coroutines, which will work well with i/o-bound workloads (and is
> already in the coroutines TS).
>

Okay, I still have my copy of Lea's book Concurrent Programming in Java, which is dated 1997, so his contributions in JAVA came before that, and we're talking about some of the reasons programming moved from C++ to JAVA in the 1990's ...

Daniel

[Chris Vine]

You may be right, but I doubt that that was such a big issue at the
time. C and C++ programmers had Butenhof's (also 1997) book Programming
with POSIX threads (which have formed the basis of C11 and C++11
threads), and Windows threads were sort-of getting established by then
also.

As far as concerns the future, Oracle seem to be ceding anything
desktop related to C# with their ejection of JavaFX from the JDK (which
I think is a shame) and the soon to be ejected Swing/AWT. It looks as
if they are concentrating on the enterprise with a view to getting out
of Java what they can while they can.

None of this alters that java is a horrible language to program in IMO
(encapsulating the worst of the 1990s in my opinion), and that you
appear to like it. À chacun son goût. There are in my view much
better languages for the JVM.

[Cholo Lennon]

So... Bonita, you are Jux und Tollerei (?) :-O

P.S. It is not rocket science to write performant code in Java.