1

Topic: Re: it is inevitable

Hello, , you wrote: And how many seconds of real time, in sense wall clock time, will be benefited by these three changeovers?

2

Re: Re: it is inevitable

Hello, , you wrote: > And where the optimizer? Most likely, has been out-of-operation by options of the compiler or any #pragma optimize

3

Re: Re: it is inevitable

> Here a common example: > > PUSH EBP > MOV EBP, ESP > PUSH ECX > MOV [EBP]-4, ECX > MOV ECX, [EBP]-4 > ADD ECX, 0000000C > CALL 100188A0 > MOV ESP, EBP > POP EBP > RET > And after that state, what translators program better the person? Without reflecting, the programmer would write all this fragment two commands: > > ADD ECX, 0000000C > JMP 100188A0 It  tail call optimization. It all modern compilers are able hardly more than almost. So or dll there was  what a thread borland delphi 5, or that is simple on what to the reasons  gathered with ungeared .

4

Re: Re: it is inevitable

Hello, , you wrote: > Which, truth, does the same. Here, any more only the translator is guilty, but also absence of normal bit lines. And yes, besides, that the optimizer with the such consults, it be included, bit literals in With ++ too are for a long time.

5

Re: Re: it is inevitable

Hello, , you wrote: > the Smart code! Reminds operation of the machine of Turing, isn't that so? You only from below looked at it at more high levels of abstractions   more interesting and there compilers do not climb

6

Re: Re: it is inevitable

Hello, , you wrote: > It was required to analyze recently one DLL. It was necessary to find what bits ustanavlivajutsja/are dumped at control of the specific USB-device. The initial text (cpp) and the documentation were inaccessible, but as given DLL was small -  it and quickly enough all found. > but what  there in all operators! In 90th years the rewriting of simple operations in a cycle with integer numbers on  gave a gain of 30 % . And now?

7

Re: Re: it is inevitable

Hello, marcopolo, you wrote: M> And now? And now write in high level language, if needed spying in  and-or . The compiler in the core perfectly is able to interpose the heaped up instructions according to the specified options; if nevertheless it is necessary to help for the compiler to select the necessary instruction, use .

8

Re: Re: it is inevitable

I will not begin to argue with title, but here and so to analyze the machine code incorrectly on one idle time :  begins already in the processor, and sometimes (and it can be frequent) the shortest machine code does not correspond to the fastest. The most widespread and very old example - xchg works more slowly three xor. For years the such collected many. Any brake , any have the latent effects, any influence speed of decoding. I would tell your thought in another way: for x86-64 the processor it is impossible to write the ideal compiler to present time. About remaining architecture I can not speak.

9

Re: Re: it is inevitable

10

Re: Re: it is inevitable

Hello, mbait, you wrote: M> I will not begin to argue with title, but here and so to analyze the machine code incorrectly on one idle time :  begins already in the processor, and sometimes (and it can be frequent) the shortest machine code does not correspond to the fastest. The most widespread and very old example - xchg works more slowly three xor. For years the such collected many. Any brake , any have the latent effects, any influence speed of decoding. I would tell your thought in another way: for x86-64 the processor it is impossible to write the ideal compiler to present time. About remaining architecture I can not speak. It is necessary to understand that for a long time already processors (x86) actually not absolutely processors, and almost that a microcomputer with the interpreter over the processor. The present processor is a risc-kernel, somewhere inside, to whose commands nobody has direct access or it is possible only with any confidential instructions and modes of operations. Much also depends on specific model of the processor, for example, on AMD, I do not know as now, there is nothing to test (is not present near at hand newer AMD), but on K8 instructions SSE2 worked in double approximately on 37 %  FPU x87. (On float faster). On Intel on the contrary, as well as followed expect. The subject was considered here, code samples for check  So that in an amicable way, whether still it is necessary to check up everywhere xchg more slowly three xor. Generally, here claims and to the documentation from firms-manufacturers. On idea, they should declare such slow instructions deprecated or  with changeover variants.

11

Re: Re: it is inevitable

Hello, mbait, you wrote: M> for x86-64 the processor it is impossible to write the ideal compiler to present time. Ideal does not exist, and good - the Intel and writes.... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

12

Re: Re: it is inevitable

Hello, CreatorCray, you wrote: CC> Hello, mbait, you wrote: M>> for x86-64 the processor it is impossible to write the ideal compiler to present time. CC> ideal does not exist, and good - the Intel and writes. I heard the mixed responses about their compiler. From "strongly is worse" to "at level gcc/clang".

13

Re: Re: it is inevitable

Hello, mbait, you wrote: M> I heard the mixed responses about their compiler. From "strongly is worse" to "at level gcc/clang". About "" it strongly is worse simply . Personally to me on set of criteria to use ICC (for a C ++) it is pleasant more.... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

14

Re: Re: it is inevitable

15

Re: Re: it is inevitable

Hello, , you wrote: > But what  there in all operators! Its rewriting on PL/1 solves at once all problems?

16

Re: Re: it is inevitable

Hello, , you wrote: > Oh these magic translators! > All they are able. They can optimize All. "And you will look in soul - the most ordinary crocodile" () It is all , and a real example when the optimizer does not work, and produces the resulted results, I so understand, will not be.

17

Re: Re: it is inevitable

Hello, , you wrote: > For example here, hardly more low. > http://rsdn.org/forum/flame.comp/7035031.1 the author: the Anonymous author Date: 28.01 09:11 Is not present, give was specific the code from the initial message > For some reason at all a solid faith in optimization miracles. Because some really were engaged in optimization. Including, a rewriting of the old assembly code on With ++. An example of a tail call from the first fragment of join of flags from the second fragment with the switched on optimizer: https://godbolt.org/g/8f3bf1

18

Re: Re: it is inevitable

19

Re: Re: it is inevitable

Hello, , you wrote: > Is not present, certainly. In this case absence in With ++ normal operators with bit lines helped. Something I did not understand it. In what the help? How much I remember, in a C ++ bit lines in language generally are not present. They are made in STL. Perhaps something changed, I on the modern C ++ do not write.

20

Re: Re: it is inevitable

Hello, , you wrote: > Whence I it will take? At me only DLL which was necessary . Well, then the theory about the bad optimizer is substantiated by nothing. > however,  very much helped to find necessary Well for this purpose and there is a debug build without  - for simplification of debugging. Itself sometimes I stick in noncritical places #pragma optimize ("", off) even in release. > and why decided, what the optimizer did not work? For example, in the resulted fragment one register, and EAX/ECX/EDX is used not. Means, someone selected them Because I saw optimized code of different modern compilers, and I know that so bad optimization does not happen. Especially the first fragment where placed on a stack a variable which is necessary only in the register. Under the link in my previous message there is a site on which it is possible to be convinced of it for the majority of compilers. It is necessary only not to forget to inscribe keys of optimization for the specific compiler (a default ).

21

Re: Re: it is inevitable

Hello, , you wrote: > that setting of bits turned to a huge chain of commands which attracted attention. Here I also speak: on PL/1 it! There bit lines are. However, I do not remember, how they there are processed. And the book near at hand is not present, there is no place to look. I, truth, am not assured completely not that compiler PL/1 will be laid down in two commands.

22

Re: Re: it is inevitable

Hello, , you wrote: > Well not in two so in three > > X=X and ' 11111111111111111000000000000001'B! ' 00000000000000000000000000000001'B; > 250180FFFF and eax,-32767 > 0D01000000 or eax, 1 > A300000000 mov X, eax > it is necessary, With ++ generates just the same machine code from just the same With ++ the code x = x and 0b11111111111111111000000000000001 | 0b00000000000000000000000000000001;

23

Re: Re: it is inevitable

Hello, , you wrote: > Well, it is finite # suckers, instead of the present boys did... So yes, there all is bad also it for a long time it is known.... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

24

Re: Re: it is inevitable

Hello, , you wrote: > He-he. Here so all the same two commands > > X=X and ' 11111111111111111000000000000001'B; > 8125000000000180FFFF and X,-32767 > X=X! ' 00000000000000000000000000000001'B; > 830D0000000001 or X, 1 > Instead of whether will be these two commands more slowly those four? Probably, expenses for two mov are with interest compensated and and or, executable in registers. In the last variant the storage cell is modified.

25

Re: Re: it is inevitable

Hello, , you wrote: > It is not known. After the first operation storage corresponds in a cache and the second operation is fulfilled faster. But much more slowly, than in the register.