Re: Compilation of lengthy C++ Files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 20 Oct 2023, 10:32 Kai Song, <kaisong1515@xxxxxxxxx> wrote:

> @David: I am sorry there was a misunderstanding with the example. You
> wrote four lines of code to be able to replace two lines of code into a
> for-loop of length 2, somewhere in a 1Bio line program where this pattern
> coincidentally occured once in one generated instance. (In the next
> instance, the "pattern" might not occur, so then you just added four
> lines.) Also, it is unclear how you would implement in turn the code which
> locates the line 200 and decides to replace it with the for-loop. Further,
> you left unclear where to place this for-loop (in line 100 or line 200?),
> both of which will lead to the wrong result in the generated program due to
> false assumption on raise-conditions.
>
> I think my initial question has been mis-correlated. I think so because we
> drift into a discussion of speed and what is better and faster and
> what-not. But this is not the question at all.
> The setting is rather: I have a list of lengthy instructions. Think of a
> grocery list. The most convenient language for me to write this grocery
> list in is c++.
> Now I don't care whether my doctor thinks I want to eat this all by myself
> or on a weekly basis, and likes that thought or not. I just need to get the
> groceries.
> I can get them myself. In this case, it would mean I have to learn to
> generate code of linear compile-complexity into assembly directly by myself.
>
> I am not even interested in the compilation per se. I just need to be able
> to evaluate the code as written.
> I am equally fine with using an interpreted language or a different
> language. But interpreters have the exact same issue: They refuse to start
> computing a flat program code when the file containing it is too big.
>

So break it up into smaller functions. You've been given the answer, but
you don't want to accept it and want to argue that it's too difficult.

Maybe that's true, but it's the only way you're going to get the code to
compile.


So suppose I have a substitution of Taylor serieses into serieses and it
> _does_ become chaotic after reordering of terms. That is after all the work
> that the program does. That is what it is made for.
> And now I just want some way to evaluate that formula once to tell me
> whether y=f(x) yields y=0 for a particular value of x. This is as basic as
> it gets.
>
> I suppose the enablement of this capability is not in the scope of GCC. Is
> there a name for this problem (evaluating lengthy list of compute
> instructions/formulas)? Where should I look to find a solution to that
> problem?
>

Use subroutines. Put some of the instructions into a separate function, and
call that function.

The way you're generating code is not going to work at scale.





> On Thu, Oct 19, 2023 at 6:03 PM David Brown <david@xxxxxxxxxxxxxxx> wrote:
>
>> On 19/10/2023 17:11, Kai Song via Gcc-help wrote:
>>
>> (It can be helpful to include attributions when replying, so that it is
>> clear who wrote what.  Thus you should have this line included:)
>>
>>  > On 19/10/2023 16:26, Jonathan Wakely via Gcc-help wrote:
>>
>>
>> >> Nothing you have said actually explains why you can't refactor the
>> >> code into utility functions that avoid doing everything in one huge
>> >> function.
>> >>
>> >
>> > Because there are no two pieces of code that are exactly identical. The
>> > relative distance of two variables being involved into an identical
>> formula
>> > will change with every line.
>> > Example:
>> > Line 1000: tmp[100]=foo(tmp[101],tmp[102]);
>> > Line 2000: tmp[200]=foo(tmp[201],tmp[203]); // dang it, not tmp[202] but
>> > tmp[203]
>> > It is like with penrose tiling. It seems all identical but the details
>> > break it. You just do not find two identical local areas. No-where. And
>> if,
>> > you have to particularly search for them by brute-force, and that should
>> > become useless whenever the particular pattern you try to find does just
>> > not exist in that particular user's instance.
>> >
>>
>> Surely this is screaming out for a table?
>>
>> const int foo_table[][3] = {
>>      { 100, 101, 102 },
>>      { 200, 201, 203 },
>>         ...
>> };
>>
>>
>>         for (int i = 0; i < 100000000; i++) {
>>                 tmp[foo_table[i][0]] =
>>                         foo(tmp[foo_table[i][1]], tmp[foo_table[i][2]]);
>>         }
>>
>> This will turn your million-line program into a four line program with a
>> big table, which will compile quickly and run faster.
>>
>>
>>
>>




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux