Refactoring dilemma

[woodb...@gmail.com]

Shalom

In an edit to this post:

https://codereview.stackexchange.com/questions/166573/messaging-and-serialization-library

, I added links to both versions of the code. Would someone take a look and
let me know what they think?


Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net

[Öö Tiib]

On Tuesday, 27 June 2017 21:32:54 UTC+3, woodb...@gmail.com wrote:
> Shalom
>
> In an edit to this post:
>
> https://codereview.stackexchange.com/questions/166573/messaging-and-serialization-library
>
> , I added links to both versions of the code. Would someone take a look and
> let me know what they think?

You want code review?

From afar looks fine. Closer look reveals too lot of function overloads
named "Marshal" for my taste.

Correctness I can't evaluate without knowing requirements to your code.

I also do not have actual data to profile your code. Everything being
named "Marshal" would likely make profiling more annoying than usual.

What else you would like to know?

[woodb...@gmail.com]

In the original version there are six functions called "Marshal".
I think this is a tame use of overloading.

> What else you would like to know?

I'm not sure whether to stick with the version that's more
verbose, but that compilers tolerate better, or to switch to
the version that uses variadics.

From a code generation perspective, I'd like to use the variadics
version as it's easier to generate since it's less verbose. But if
compilers aren't ready for it, it may be pushing things too much.


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[Öö Tiib]

When you are not sure what is better then it can be that neither is
better. For example it can be different per project what is better.
On such cases it may make sense to add optional choice.

[woodb...@gmail.com]

If I could find a compiler that does better than g++ 7.1.1, g++ 8.0.0
and clang 4.0.0, that would be encouraging.

If someone who has clang 5 installed would try to build the example
programs :

git clone https://github.com/Ebenezer-group/onwards.git
cd onwards
make example

That will build two executables and it runs the size command on
them. Take note of the size of the text segment of the executable
called :send_example."

Now do the same thing for the variadic version:

git clone https://bitbucket.org/woodbrian/onwards.git
cd onwards
make example

Then post here what the two sizes are. Thanks.


Brian
Ebenezer Enterprises
http://webEbenezer.net

[Öö Tiib]

On Wednesday, 28 June 2017 06:07:02 UTC+3, woodb...@gmail.com wrote:
>
> If I could find a compiler that does better than g++ 7.1.1, g++ 8.0.0
> and clang 4.0.0, that would be encouraging.

You measure "better" with size of executable generated by compiler?
But that is not so important about software. Most important is that
it is doing correct things. Then it is important that it is easy to
use. Then it is important that it performs well. Size of executable
is later in list typically.

[woodb...@gmail.com]

C++ is known for its zero-overhead abstraction. I'm trying to figure
out if there's something I'm doing wrong or if the compilers I've tried
are not able to provide abstraction for free in this area.

[Daniel]

On Wednesday, June 28, 2017 at 11:18:21 AM UTC-4, woodb...@gmail.com wrote:
>
> C++ is known for its zero-overhead abstraction.

Hardly. Except in trivial cases, copying a value or a ref count is generally more expensive than copying a reference in a language with gc. Move isn't zero overhead either. The complexity of C++ presents a challenge to optimizers, in some cases the possibility of aliasing gives the edge to FORTRAN. And then there's streams ...

Daniel

[David Brown]

C++ is known for getting close to zero overhead from features you don't
use - but that is /speed/ overhead. There is plenty of overhead in code
size. For example, implementations strive to make exceptions free in
terms of speed when they are not thrown - but doing so means adding
quite a bit to the code size.

For most uses, code size is not a serious issue. Speed /might/ be an
issue, depending on the usage.

[woodb...@gmail.com]

The following quote is from this page:
http://blog.felipe.rs/2014/09/23/c-plus-plus-variadic-templates/

"C++’s strength mostly comes from the zero-cost abstractions it provides.
Stroustrup explains what it means in the C++ papers:

In general, C++ implementations obey the zero-overhead principle: What you
don’t use, you don’t pay for [Stroustrup, 1994]. And further: What you do use,
you couldn’t hand code any better."

I'm having a problem with the last part of that statement.

I don't think anyone claims moving can/should be free.

[Öö Tiib]

Huh? I felt I asked why you aim for size over speed, you tell something
that is not from this world.

Zero overhead? That means C++ produces ideal assembler? You misunderstood.
It is zero overhead principle ... aim ... goal. Actual compilers can not
translate code into ideal assembler. There is always some overhead.
Now even if there was a super compiler then the ideally short assembler
for most algorithms has some speed overhead compared to ideally fast
assembler for same algorithm (that has some size overhead). So zero
overhead in both senses would be still simply impossible.

So why you value size over speed?

[woodb...@gmail.com]

On Wednesday, June 28, 2017 at 6:52:12 PM UTC-5, Öö Tiib wrote:
> On Wednesday, 28 June 2017 18:18:21 UTC+3, woodb...@gmail.com wrote:
> > On Wednesday, June 28, 2017 at 1:10:35 AM UTC-5, Öö Tiib wrote:
> > > On Wednesday, 28 June 2017 06:07:02 UTC+3, woodb...@gmail.com wrote:
> > > >
> > > > If I could find a compiler that does better than g++ 7.1.1, g++ 8.0.0
> > > > and clang 4.0.0, that would be encouraging.
> > >
> > > You measure "better" with size of executable generated by compiler?
> > > But that is not so important about software. Most important is that
> > > it is doing correct things. Then it is important that it is easy to
> > > use. Then it is important that it performs well. Size of executable
> > > is later in list typically.
> >
> > C++ is known for its zero-overhead abstraction. I'm trying to figure
> > out if there's something I'm doing wrong or if the compilers I've tried
> > are not able to provide abstraction for free in this area.
>
> Huh? I felt I asked why you aim for size over speed, you tell something
> that is not from this world.

There's a link between size and speed:

int main (){return SUCCESS;}

>
> Zero overhead? That means C++ produces ideal assembler? You misunderstood.
> It is zero overhead principle ... aim ... goal. Actual compilers can not
> translate code into ideal assembler. There is always some overhead.

The question is if there's unnecessary overhead.

This is quote from earlier in the thread:

"And further: What you do use, you couldn’t hand code any better."

In one case, my use of variadic templates yields larger results from
compilers than if I don't use variadics. But in two other cases, compilers
appear to produce better results.

Supporting both options as you suggested earlier would be a headache
for me. I don't have resources to support lots of options right now.
Rebbe Nachman said, "All the world is just a narrow bridge -- the most
important thing is not to be afraid." I have to figure out one of these
options to use for the time being. Is Russia attacking Ukraine with
cyberattacks? Rebbe Nachman was from Ukraine if I remember right.

> Now even if there was a super compiler then the ideally short assembler
> for most algorithms has some speed overhead compared to ideally fast
> assembler for same algorithm (that has some size overhead). So zero
> overhead in both senses would be still simply impossible.
>
> So why you value size over speed?

Maybe someone with g++ 7.2 or clang 5 could build the two
approaches and report the results.


Brian
Ebenezer Enterprises - If you like bread, you should
love the Ukraine -- its the bread basket of the world.

http://webEbenezer.net

[Gareth Owen]

woodb...@gmail.com writes:

> There's a link between size and speed:
>
> int main (){return SUCCESS;}

There is. But it sure isn't smaller == faster.

[Ian Collins]

The code doesn't compile with Clang5 (or at least the library it uses)

In file included from ./SendBuffer.hh:2:
./ErrorWords.hh:30:13: error: no matching member function for call to
'append'
whatStr.append(s);
~~~~~~~~^~~~~~

...

Also string_view is still in std::experimental.

--
Ian

[Öö Tiib]

On Thursday, 29 June 2017 04:51:07 UTC+3, woodb...@gmail.com wrote:
> On Wednesday, June 28, 2017 at 6:52:12 PM UTC-5, Öö Tiib wrote:
> > On Wednesday, 28 June 2017 18:18:21 UTC+3, woodb...@gmail.com wrote:
> > > On Wednesday, June 28, 2017 at 1:10:35 AM UTC-5, Öö Tiib wrote:
> > > > On Wednesday, 28 June 2017 06:07:02 UTC+3, woodb...@gmail.com wrote:
> > > > >
> > > > > If I could find a compiler that does better than g++ 7.1.1, g++ 8.0.0
> > > > > and clang 4.0.0, that would be encouraging.
> > > >
> > > > You measure "better" with size of executable generated by compiler?
> > > > But that is not so important about software. Most important is that
> > > > it is doing correct things. Then it is important that it is easy to
> > > > use. Then it is important that it performs well. Size of executable
> > > > is later in list typically.
> > >
> > > C++ is known for its zero-overhead abstraction. I'm trying to figure
> > > out if there's something I'm doing wrong or if the compilers I've tried
> > > are not able to provide abstraction for free in this area.
> >
> > Huh? I felt I asked why you aim for size over speed, you tell something
> > that is not from this world.
>
> There's a link between size and speed:

There is very rough correlation but no relation.

>
> int main (){return SUCCESS;}

Programs that do nothing useful are not what we
discuss I hope.

> >
> > Zero overhead? That means C++ produces ideal assembler? You misunderstood.
> > It is zero overhead principle ... aim ... goal. Actual compilers can not
> > translate code into ideal assembler. There is always some overhead.
>
> The question is if there's unnecessary overhead.

Yes, non-ideal assembler has always some unnecessary overhead.

> This is quote from earlier in the thread:
> "And further: What you do use, you couldn’t hand code any better."

That is again principle, the goal to pursue, the philosophy how to go,
not something that actual C++ compilers have somehow magically
achieved already.

> In one case, my use of variadic templates yields larger results from
> compilers than if I don't use variadics. But in two other cases, compilers
> appear to produce better results.
>
> Supporting both options as you suggested earlier would be a headache
> for me. I don't have resources to support lots of options right now.

The cheapest is just to do nothing if you ask that from me.

> Rebbe Nachman said, "All the world is just a narrow bridge -- the most
> important thing is not to be afraid." I have to figure out one of these
> options to use for the time being. Is Russia attacking Ukraine with
> cyberattacks? Rebbe Nachman was from Ukraine if I remember right.

To my knowledge current cryptoworm (where Ukraine got lot of damage)
seem modified versions of EternalBlue and EternalRomance. Those two are
exploits from bigger set of hacking tools that were developed by the
National Security Agency of United States Department of Defence and that
last year leaked onto the Internet by hackers. Microsoft has already
patched the holes of those exploits but unfortunately in countries like
Ukraine and Russia there are significant usage of pirated versions of
Windows. Anyway it sounds like nonsense to accuse Russians of those
worms.

>
> > Now even if there was a super compiler then the ideally short assembler
> > for most algorithms has some speed overhead compared to ideally fast
> > assembler for same algorithm (that has some size overhead). So zero
> > overhead in both senses would be still simply impossible.
> >
> > So why you value size over speed?
>
> Maybe someone with g++ 7.2 or clang 5 could build the two
> approaches and report the results.

So ... why you ignore speed?

[Chris Vine]

On Wed, 28 Jun 2017 18:50:40 -0700 (PDT)
woodb...@gmail.com wrote:
> There's a link between size and speed:
>
> int main (){return SUCCESS;}

Your argument seems to be that faced with two binaries compiled from
the same source code which are of different size, the smaller one is
going to be the faster.

However, some speed optimizations such as loop unrolling will increase
binary size, but run faster. There is often a size and speed trade off
to be made. For example, with gcc code compiled with -Os will be
smaller than code compiled with -O2, but is likely to run slower: -Os
contains most of -O2 except those optimizations which increase code
size, and includes some addition code size reducing options.

If small binary size is more important to you than speed, the first
thing to do is to use -Os optimization. But you need to question
yourself why you prefer small size to speed.

[woodb...@gmail.com]

I think that's the problem. On FreeBSD (TrueOS) with
clang 4 it builds fine. String_view isn't in experimental
for clang 4. Thanks for the info.

[woodb...@gmail.com]

If the transformation I made produced larger results in all
cases, I'd probably give up on the variadic option. But
in two cases, the compilers seemed to handle it well and in
one case not. That's my basis for hoping that the third case
is an aberration and eventually can be straightened out.



Brian
Ebenezer Enterprises - "Do not be conformed to this world, but
be transformed by the renewing of your mind." Romans 12:2

http://webEbenezer.net

[woodb...@gmail.com]

There's an updated version of clang 5 now:
https://groups.google.com/forum/#!topic/comp.lang.c++/OB5cGxihXa4

Would someone mind checking this again?
https://github.com/Ebenezer-group/onwards

[Mr Flibble]

On 10/09/2017 03:21, woodb...@gmail.com wrote:

> Would someone mind checking this again?
> https://github.com/Ebenezer-group/onwards

Nobody "checked it" before and nobody will check it "again". Your code
is commercial non-open source and you expect people to check the public
API for free? Dream on. Your project not only isn't interesting enough
for people to bother it is also totally the wrong approach to
serialization (online compilation) when there are plenty of adequate
free and open source alternatives available.

It is well past the time for you to spend your energies on new,
different more interesting and useful projects.

/Flibble

[woodb...@gmail.com]

On Saturday, September 9, 2017 at 10:26:02 PM UTC-5, Mr Flibble wrote:
> On 10/09/2017 03:21, woodb...@gmail.com wrote:
>
> > Would someone mind checking this again?
> > https://github.com/Ebenezer-group/onwards
>
> Nobody "checked it" before and nobody will check it "again".

Ian checked it previously.

> Your code is commercial non-open source

The code generated by the C++ Middleware Writer and the
code here:
https://github.com/Ebenezer-group/onwards

are open source. When the dust settles, I may be
responsible for more open source code than anyone.

> and you expect people to check the public
> API for free? Dream on. Your project not only isn't interesting enough
> for people to bother it is also totally the wrong approach to
> serialization (online compilation) when there are plenty of adequate
> free and open source alternatives available.

The future si bright for on-line code generation.

>
> It is well past the time for you to spend your energies on new,
> different more interesting and useful projects.

There are a lot of interesting things with the CMW that
I hope to keep working on.

[woodb...@gmail.com]

On Saturday, September 9, 2017 at 11:27:08 PM UTC-5, woodb...@gmail.com wrote:
> On Saturday, September 9, 2017 at 10:26:02 PM UTC-5, Mr Flibble wrote:
> > On 10/09/2017 03:21, woodb...@gmail.com wrote:
> >
> > > Would someone mind checking this again?
> > > https://github.com/Ebenezer-group/onwards
> >
> > Nobody "checked it" before and nobody will check it "again".
>
> Ian checked it previously.
>
> > Your code is commercial non-open source
>
> The code generated by the C++ Middleware Writer and the
> code here:
> https://github.com/Ebenezer-group/onwards
>
> are open source.

I want to make a correction to that: Some of the code
generated by the C++ Middleware Writer is open source.
Users decide whether to make it closed or open source.

[woodb...@gmail.com]

I was able to test this now on FreeBSD with clang 5.0.0
and the code compiled fine. I had heard a few months
ago on a Boost list that clang 5 was getting competitive
with gcc in terms of generating smaller executables. I
didn't find that to be the case with two programs that I
build. They were still significantly larger than their
gcc counterparts.