Well what about optimizations ?

For other topics related to the FreeBASIC project or its community.
Mihail_B
Posts: 271
Joined: Jan 29, 2008 11:20
Location: Romania
Contact:

Well what about optimizations ?

Postby Mihail_B » Feb 26, 2009 18:53

D.a
Hello there !

Well for short.... what about optimizations ....
They are not wet present in compiler's command line ....
Like constant propagation, register allocation, bla-bla-bla

We know all C compilers do have -O 0/1/2 options (and so on) .......
What are you waiting you all lazy .... (ha-ha-ha)

Any way fbc does a good job ,,, but an optimizer would be such
a nice thing to add ....
Have fun
Bye !
(any way fb is may favorite ....)
KristopherWindsor
Posts: 2428
Joined: Jul 19, 2006 19:17
Location: Sunnyvale, CA
Contact:

Postby KristopherWindsor » Feb 26, 2009 23:35

The only major planned optimizations are through a GCC / C emitter that will theoretically be developed in the very distant future.
Go back to C. =P
counting_pine
Site Admin
Posts: 6190
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Postby counting_pine » Feb 27, 2009 7:28

Note that FBC aready supports constant propogation, and a few other nice things, like multiplication and division by powers of two.
DOS386
Posts: 798
Joined: Jul 02, 2005 20:55

Re: Well what about optimizations ?

Postby DOS386 » Mar 01, 2009 6:25

Mihail_B wrote:Well for short.... what about optimizations ....
Like constant propagation, register allocation, bla-bla-bla
We know all C compilers do have -O 0/1/2 options (and so on) .......
What are you waiting you all lazy"


"all lazy" is currently just one developer, and "optimizing compiler" is a very expensive task (GCC has had several 100 of developers for 20 years), so what ...
Kot
Posts: 336
Joined: Dec 28, 2006 10:34

Postby Kot » Mar 01, 2009 17:36

But fb afaik that way or another sits on the crt library and there are many commands that can be replaced with calls to crt with great speed boost to the compiled programs, e.g. replacing original fb calls to disk with those using crt (you know, open file could use crt without changing the sytnax).
DOS386
Posts: 798
Joined: Jul 02, 2005 20:55

Postby DOS386 » Mar 02, 2009 3:19

Kot wrote:But fb afaik that way or another sits on the crt library and there are many commands that can be replaced with calls to crt with great speed boost to the compiled programs, e.g. replacing original fb calls to disk with those using crt (you know, open file could use crt without changing the sytnax).


1. Minor only speedup in I/O only (not in algorithms)
2. with changing the syntax
3. unrelated to compiler core inefficiency AKA "optimization"
BastetFurry
Posts: 255
Joined: Jan 05, 2006 0:56

Postby BastetFurry » Mar 02, 2009 10:29

@Kot:
fbc is opensource, so, if you want it do it or pay someone to do it for you.
Just dont sit here and call other people lazy. :>

And BTW, you can always use the C runtime if you want.
Richard
Posts: 2998
Joined: Jan 15, 2007 20:44
Location: Australia

Postby Richard » Mar 02, 2009 11:23

If you want code that can be read and debugged by humans then continue to use FB. FB implements quite a few optimizations that we do not see, for example x^2 becomes x*x and avoids exponentiation. FB is pretty quick because it was written with speed in mind. To get the best speed from an algorithm coded in FB it is probably necessary to use pointers and assembly code optimizations of the inner loops. I doubt that the speed of FB code could be doubled by using all possible optimization techniques. Computer hardware doubles it’s speed every 18 months, so we are not that far behind. Without a C emitter FB cannot benefit from available C optimization solutions.
If you really need more speed then write, debug and optimize your code in C, or buy a faster PC. An alternative might be to become a developer, or employ a programmer to work as a developer and finish the C emitter. Developers time is not a commodity, it is a scarce and valuable non-renewable resource.
marcov
Posts: 2938
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » Mar 02, 2009 17:09

Richard wrote:Computer hardware doubles it’s speed every 18 months, so we are not that far behind. Without a C emitter FB cannot benefit from available C optimization solutions.


(This is a classic misconception. The original Moore's law was about number of transistors integrated in a VLSI chip, not about speed)

If you really need more speed then write, debug and optimize your code in C, or buy a faster PC. An alternative might be to become a developer, or employ a programmer to work as a developer and finish the C emitter. Developers time is not a commodity, it is a scarce and valuable non-renewable resource.


(I would not spend too much time on implementing a lot of these x*x peephole optimizations. Either go with the C backend way, or re-setup the FB own CG with as good as possible generic fundaments for the optimizer, like register allocation (SSA based if possible), liveliness analysis, inlining etc.

Because if you now spend a lot of time in the micro-optimization, you will have to do them all over again if you change something in the backend. And you will, the microoptimizations alone do not yield that much. It only gets interesting if optimizations start to interact, and whole sequences are optimized away.

We suffered grossly with this between 1.0 and 2.0, one of the reasons why that transition took 5 _years_)
Zippy
Posts: 1295
Joined: Feb 10, 2006 18:05

Postby Zippy » Mar 03, 2009 1:00

marcov wrote:(This is a classic misconception. The original Moore's law was about number of transistors integrated in a VLSI chip, not about speed)


I don't see "Moore" or "transistor" in Richard's post.

Moore originally postulated that transistor density would double very 12 months, then later revised that to 24 months. David House (also of Intel) predicted that given 24 month transistor density doubling that computer performance would double every 18 months - he was very close, it has ranged nearer to 20 months. Richard stated 18 months, arguably accurate, unless you wish to disassociate performance and speed.

Moore didn't predict 18 months in either context, not density which he did address nor speed which he did not.
Richard
Posts: 2998
Joined: Jan 15, 2007 20:44
Location: Australia

Postby Richard » Mar 03, 2009 2:06

@marcov: I was not directly quoting Moore’s Law. I was applying a scaling rule which states that improving the resolution of manufacturing optics by 41% will double the number of transistors on the chip, that halves the transistor area and gate capacitance, which halves the power consumption and doubles the speed of the transistors. This more than doubles the speed of the technology because there is twice as much, going twice as fast, for the same power in the same package. Not only can this double the width of your registers and data paths, or provide you with twice as many CPU cores on the same chip, but it also doubles the memory capacity and speed because memory is on another chip is also covered by the same scaling rules. So if Moore’s law holds and the number of transistors on a chip doubles every 18 months, it follows that we can expect up to a four times increase in system speed. I am being conservative and backed off to claim only double the speed every 18 months.

I have made the point that the speed of compiled code is not everything and that it is hard to improve the speed of the FB compiled code by more than a factor of two, which is what technology does every 18 months.

With only one developer we can really only consider bug fixing. If we had more developers then we could take the next step in the evolution of FB. This topic suggests that the next evolutionary step should be optimization. The majority of the easy speed improvements have been implemented. Clearly there is no point wasting time on further minor or specific refinements if investment in completion of the C emitter could lead to a significant speed improvement of most compiled code.

If the C emitter is a sufficiently sexy problem and will yield a significant speed improvement then “free market economics” suggests that a “volunteer developer” will materialise to work on the problem. The fact that it has not already happened suggests that it is not a sexy problem or the possible improvement in speed probably does not justify the work needed. Maybe no one has properly evaluated it as a project.
Zippy
Posts: 1295
Joined: Feb 10, 2006 18:05

Postby Zippy » Mar 03, 2009 2:59

Moore's.. Law.. not.. 18.. months..

http://www.intel.com/technology/mooreslaw/

"about two years" is not 'about 18 months'.

-----

Optimization is fine, just fine, but are there outstanding complaints about fb performance? Need? Is there some overwhelming omnipresent need for optimization? Or is this yet another specious argument about what isn't but could be if only and whatever.
marcov
Posts: 2938
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » Mar 03, 2009 12:19

Zippy wrote:
marcov wrote:(This is a classic misconception. The original Moore's law was about number of transistors integrated in a VLSI chip, not about speed)


I don't see "Moore" or "transistor" in Richard's post.


I also don't see a good definition of his "performance", and that was what I was hinting on, not the exact time of Moore.

Currently, the trend started with MMX/SSE, namely that not every bit of extra semiconductor complexity goes into improving straight performance for programs not specifically written for the newer technologies (SIMD in the past, multi core now)

And that's what Richard was implying, and what I was hinting at.
arenth
Posts: 511
Joined: Aug 30, 2005 6:22

Postby arenth » Mar 03, 2009 18:58

Richard, the problem isn't necessarily that a C emitter, or a GCC compatible frontend won't generate a signifigant speed increase, it most likely will generate a noticeable speed increase. Sure while its true it wont generate a factor of two like say a new faster processor, it wont cost (me) any money either.

I would wager that there are two groups of people who view the idea of a C emitter, or similar: Those who lack the knowledge and so aren't daunted by the task but ultimately can't accomplish it, and those who posess at least a mediocre understanding of what it would take to translate from FB to C, and will most definately not attempt to undertake such an immense project.

After all most of us are hobby programmers who'd rather be making games, then working on the horrifying internals of any compiler. Honestly I can't imagine the effort it takes to add new features to FB, considering all the QB muck it has to wade through.
MichaelW
Posts: 3500
Joined: May 16, 2006 22:34
Location: USA

Postby MichaelW » Mar 03, 2009 22:03

Richard wrote:So if Moore’s law holds and the number of transistors on a chip doubles every 18 months, it follows that we can expect up to a four times increase in system speed. I am being conservative and backed off to claim only double the speed every 18 months.

While I can’t find fault with your reasoning regarding a theoretical speed increase, doubling every 18 months would mean a more than 100x increase in speed over the last 10 years. There has been a substantial increase in the effective system speed over that period, but except for certain specialized tasks it’s been nothing like 100x.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 5 guests