Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compilers > #2188 > unrolled thread

Optimization techniques

Started by"Rick C. Hodgin" <rick.c.hodgin@gmail.com>
First post2019-04-17 09:42 -0400
Last post2019-09-26 20:35 -0700
Articles 3 on this page of 23 — 10 participants

Back to article view | Back to comp.compilers


Contents

  Optimization techniques "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-17 09:42 -0400
    Re: Optimization techniques Hans Aberg <haberg-news@telia.com> - 2019-04-17 18:11 +0200
    Re: Optimization techniques George Neuner <gneuner2@comcast.net> - 2019-04-18 04:07 -0400
      Re: Optimization techniques "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-18 11:22 -0400
        Re: Optimization techniques George Neuner <gneuner2@comcast.net> - 2019-04-19 15:48 -0400
      Re: Optimization techniques Hans Aberg <haberg-news@telia.com> - 2019-04-19 00:52 +0200
    Re: Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-04-19 08:49 +0000
      Re: Optimization techniques "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-19 11:48 -0400
        Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-04-23 09:38 +0200
      Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-04-23 09:18 +0200
    Re: Optimization techniques Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2019-04-20 00:27 +0200
      Re: Optimization techniques "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-19 16:11 -0700
        Re: Optimization techniques Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2019-04-20 19:47 +0200
          Re: Optimization techniques "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-24 10:16 -0400
      Re: Optimization techniques George Neuner <gneuner2@comcast.net> - 2019-04-20 18:59 -0400
      Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-04-23 09:43 +0200
        Re: Optimization techniques Martin Ward <martin@gkc.org.uk> - 2019-04-26 20:10 +0100
          Re: Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-04-26 21:11 +0000
          Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-04-28 17:22 +0200
            Re: Optimization techniques Gene Wirchenko <genew@telus.net> - 2019-04-30 18:07 -0700
              Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-05-01 09:03 +0200
      Re: Optimization techniques "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2019-04-26 13:39 +0100
    Re: Optimization techniques rockbrentwood@gmail.com - 2019-09-26 20:35 -0700

Page 2 of 2 — ← Prev page 1 [2]


#2237

FromDavid Brown <david.brown@hesbynett.no>
Date2019-05-01 09:03 +0200
Message-ID<19-05-001@comp.compilers>
In reply to#2234
On 01/05/2019 03:07, Gene Wirchenko wrote:
> On Sun, 28 Apr 2019 17:22:26 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
>
> [snip]
>
>> Obviously compiler writers are expected to pay more attention to these
>> details than someone making a Usenet post!
>
>       What?  I can not trust the godlings in comp.compilers?
>

Maybe others, but not me.  I give my opinions, advice and help freely on
Usenet, with the best of intentions but not necessarily the best of
results or as much time and thought as for serious work.  If I say
something wrong, I guarantee you your money back.  I think this applies
to most posters.
[This newsgroup is moderated, not peer reviewed.  I look at all the
messages and I will send back messages that are incoherent or with
obvious mistakes ("Linux Torvalds invented C++") but I certainly don't
claim to be omniscient. -John]

[toc] | [prev] | [next] | [standalone]


#2210

From"Derek M. Jones" <derek@_NOSPAM_knosof.co.uk>
Date2019-04-26 13:39 +0100
Message-ID<19-04-026@comp.compilers>
In reply to#2196
All,

On 19/04/2019 23:27, Hans-Peter Diettrich wrote:
> I'm always a bit sceptic when C/C++ and "safe" occur in the same
> sentence. AFAIR a C compiler is allowed to ignore parentheses when
> reordering expressions, what can lead to numeric instabilities.

Not true:
"In the abstract machine, all expressions are evaluated as specified by
the semantics. "

https://c0x.coding-guidelines.com/5.1.2.3.html

--
Derek M. Jones
blog:shape-of-code.coding-guidelines.com
[Keeping in mind the "as if" rule which lets the compiler do whatever
it wants so long as the result is the same. -John]

[toc] | [prev] | [next] | [standalone]


#2362

Fromrockbrentwood@gmail.com
Date2019-09-26 20:35 -0700
Message-ID<19-09-012@comp.compilers>
In reply to#2188
On Wednesday, April 17, 2019 at 8:42:24 AM UTC-5, Rick C. Hodgin wrote:
> Are there resources someone can point me to for learning more about
> time-honored, long-established, safely applied, optimization
> techniques for a C/C++ like language?

cparser uses libfirm as an optimization engine.

https://github.com/libfirm/cparser

Get your hands dirty, experimenting with it; while searching links on each of
the methods that libfirm uses (e.g. looking up 'common subexpression
elimination' https://en.wikipedia.org/wiki/Common_subexpression_elimination )
when it mentions it. A master list of sorts can be found here (
https://en.wikipedia.org/wiki/Optimizing_compiler ).

> I'm walking the abstract syntax tree and am able to find many kinds of
> optimizations, but I would like to learn some theory or pitfalls of
> various types of optimizations applied.

One kind of optimization it does NOT do - which I did to the whole cparser
source - is language-level optimization (i.e. refactoring, reengineering,
recoding).
https://refactoring.com/
https://en.wikipedia.org/wiki/Code_refactoring

This is the, by far, more important set of optimizations; since it eliminates
the large, significant accumulation of code debt (
https://en.wikipedia.org/wiki/Technical_debt ) that accrues in large
distributions ... and that has seriously plagued the entire GNU codebase ...
when the continual need for refactoring is ignored.

When left untended for too long, a code base transforms into legacy code (
https://en.wikipedia.org/wiki/Legacy_code ). Then, we talk about legacy rescue
or legacy code refactoring.

That should also be handled by and integrated within the compiler, as an
additional optional front-end only optimization stage, to whatever extent is
possible. A key ingredient in this process is a nuts and bolts level
Artificial Intelligence tool/method known as formal concept lattice analysis.

"Detecting Software Patterns Using Formal Concept Analysis"
https://pdfs.semanticscholar.org/0dc7/f972dcfcde866258abfc3d46b886df89ed68.pd
f

"Revealing Class Structure with Concept Lattices"
http://www.cs.cmu.edu/~udekel/research/Msc/tse_draft_fca.pdf

All of this should be considered as part of the compilation and optimization
process. Any code analysis/[re-]synthesis is compilation ... even if it
entails automating elements of the task of software engineering, itself.
Refactoring, itself, is the optimization stage of that process.

I'm also experimenting with hybridizing singular value decomposition and
factor analysis with formal concept lattices. For instance, I have a large set
of graphics routines (about 150) that needs to be refactored and reintegrated.
I'm running all 3 types of analyses on it and working my way up to a utility
that can do all 3 in tandem.

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.compilers


csiph-web