The splendour and poverty of the PLO - page 2

New comment
 
Integer:
Why should I understand the compilation mechanisms? Just to believe that a bad result is better than a good one?

To write tests properly and not to mislead people.

You don't even understand what you have written in your tests and what you are actually testing.


This is the consequence of mass training in dotnet and similar languages. Programmers have absolutely no desire to understand what really works and how it works.

 
Renat:

To write tests properly and not to mislead people.

You don't even understand what you have written in your test and what you are actually testing.


Such are the consequences of mass training in dotnet and similar languages. Programmers have absolutely no desire to understand what and how things work in reality.

Everyone has their own blinders over their eyes, like horses (so as not to see too much).

One sees his own, the other sees his own. But that doesn't mean that both are right or wrong.

The truth is somewhere near.

The developer wanted one thing and got another. It does not mean that the task is accomplished. It works, though. Maybe not in the way it was expected or wanted.

The user makes his test (which is quite predictable). It doesn't mean that the test will satisfy all the parties.

The truth is out there.

The speed of operations matters too much. This is not my whim, this is life.

And you have to prove it with tests, not words.

 
Vinin:

Speed of operation matters too much. This is not my whim, this is life.

And you have to prove it with tests, not words.

I immediately pointed out the errors in the proposed tests. Then I explained the point several times.

 

Virtual methods will always be more expensive than normal methods, but testing optimising compilers should be done correctly with an understanding of what/how is being minimised and optimised.

In this case, we have not yet implemented an optimization method to automatically convert a virtual function to a regular one (other compilers do this when possible), which will immediately change the results of this test and mislead again (a virtual method call may suddenly be faster than a regular one).

 
Renat:

Virtual methods will always be more expensive than normal methods, but testing optimising compilers should be done correctly with an understanding of what/how is being collapsed and optimised.

In this case, we have not yet implemented an optimization method to automatically convert a virtual function to a regular one (other compilers do this when possible), which will immediately change the results of this test and mislead again (a virtual method call may suddenly be faster than a regular one).

That is - at this point, Integer is right. And it was impossible to acknowledge and explain at once. Or is something preventing it?
 
Vinin:
That is - at this stage, Integer is right. Couldn't you just admit and explain right away. Or is there something in the way?
Reread the whole topic carefully, please.
 
Renat:

Virtual methods will always be more expensive than conventional methods, but testing optimising compilers should be done correctly with an understanding of what/how is being minimised and optimised.

In this case we haven't implemented the optimization method of automatically converting a virtual function to a regular function (other compilers do that when possible), which will immediately change the results of this test and mislead again (a call of a virtual method could suddenly be faster than a regular one).

Actually, it's not the compiler that's being tested, but two methods of solving the same problem. It doesn't matter how the fridge hums, it's how it freezes that's important.

 
Integer:

Actually, it wasn't the compiler that was being tested, but two methods of solving the same problem. It doesn't matter how the refrigerator hums oooh or wooh, what matters is how it freezes.

You tested incorrectly by presenting a simplified and degenerate test case. It's not a problem, it's a degenerated to nothing example.

You haven't paid attention to the compiler's optimizer which is heavily optimizing the option of direct calls to dummies.

 
Renat:

You have tested incorrectly by presenting a simplified and degenerate test case. This is not a task, but exactly a degenerated to nothing example.

You haven't paid attention to the compiler's optimizer which is heavily optimizing the option of direct calls to dummies.

There were two more variants of testing after that - 2 with non-empty functions and 3 with unique functions - and the results were similar. Variant 1 was still conducted in C#, but the result was the opposite.
 
Renat:
Reread the whole topic carefully, please.
You can read forever, but you have to give the facts. Conduct a test and show the numbers. We need to prove that Integer is wrong. He (and not only him) needs such a result. I too can talk a lot, but I try not to do it without facts. I trust Integer's test results. But there was no contrary, only words
1234567
New comment