Optimize code size

[fromVB]

does c compiler produce a faster code then hand-written assembly?

That is like asking if a civic (c compiler) is faster than a ferrari (asm). It all depends on who is at the wheel...

With a skilled programmer, C will NEVER be faster than asm.
With an unskilled programmer, asm could be faster, but it depends on which skills he is lacking.

Is PB the Ferrari? I read that it is translated to assembly right?

[Thorium]

I did wrote that the question is if your code is fast enough or not. You dont optimize if its fast enough. On my programs i need to use ASM to make them fater. If you just develop GUI's, which doesnt realy do anything than its true that you dont need to optimize. I disagree that most programs are that way. And if we look at handhelds most software is incredibily slow on them, because the coders dont optimize it.
The writer of the article even considers C++ a low level language, its allready a high level language. And beating java code on ARM platforms is extremly easy. ARM assembly allows a lot low level optimizations which rewquire the optimiezer to know the purpose of the code, which no compiler does. Also there are hardly any software that uses SIMD instructions on ARM.

does c compiler produce a faster code then hand-written assembly?

That is like asking if a civic (c compiler) is faster than a ferrari (asm). It all depends on who is at the wheel...

With a skilled programmer, C will NEVER be faster than asm.
With an unskilled programmer, asm could be faster, but it depends on which skills he is lacking.

Is PB the Ferrari? I read that it is translated to assembly right?

No, every compiler is translating to ASM or directly to machine code.
ASM isnt fast just because it's ASM. Its faster because it allows you to specialize and optimize your code on the lowest possible level.
If you dont do that optimizations your ASM code is likly slower than the one generated by a compiler. Because compilers do a lot of optimizations. But they are not smart, they dont realy know what your code does and so cant cut out parts you dont realy need for the specific task.

[TI-994A]

No, every compiler is translating to ASM or directly to machine code.
ASM isnt fast just because it's ASM. Its faster because it allows you to specialize and optimize your code on the lowest possible level.
If you dont do that optimizations your ASM code is likly slower than the one generate by a compiler. Because compilers do a lot of optimizations. But they are not smart, they dont realy know what your code does and so cant cut out parts you dont realy need for the specific task.

Hi Thorium. Would it be fair to say that well-written and optimized PureBasic code would be translated into optimized Assembly code, and ultimately compiled into efficient executables?

[luis]

I'm not Thorium, but IMHO the answer is probably no, depending on the meaning of optimization for you.
The only way to really optimized code is to write it in ASM directly.

Then you:

1) know what the purpose of the algorithm is, and can plan the ASM in the best way accordingly
2) can optimize for size, for speed, for memory access, whatever
3) can decide if you want to target some specific processor or family of processors sharing a common extended instruction set able to give a boost to your specific algorithm
4) can use unconventional or mixed ways to pass parameters between portion of the code

etc.

Moreover an optimized (for something.. speed size etc) PB code can probably be written using a different approach in ASM, so the direct translation of the optimized BASIC code (who must obey to some specific language constrains) can be less optimized (for the same something) than the same code rewrote using ASM from scratch.

Some compilers (like microsoft of intel c++ compilers) have good optimizers, and can do some clever optimizations PB doesn't dream about, but even those pales compared to hand written ASM.

PB has going for him it's a quite simple language and extremely rigid compared to C++ (for example).
In C++ you can write some very complex source code (sometime difficult to read too) and the compiler has an harder time to "unwrap it" and then optimize it.
In PB the statements are more rigid, the expressions are more rigid, pointer mathematics is more simple, etc.
All this make generating code easier and consistent. So the code generated (even if not highly optimized) can be well organized by hand in advance by the compiler author to a large extent. So there is some kind of balance. It's good code for a compiler, a little bloated compared to hand written ASM, and almost never fast as ASM (and quite often this it totally irrelevant).

On the other end most of the time people think about what advantage they could get from using a particular procedure written in ASM when the algorithm they are using is not optimal and they could get a 3x-10x boost without ASM making different choices in BASIC.

[Tenaja]

No, every compiler is translating to ASM or directly to machine code.
...
Because compilers do a lot of optimizations.
...

Thorium, these statements can be a little misleading to newbies, for a couple reasons.

1. The term "compiler" has become standard use for Java these days, too, and Java does NOT translate to asm or machine code; it translates to bytecode, which is then later translated to fit the machine it is executed on. I know, this is splitting hairs, but I thought it worth saying. Java has really blurred the line between interpreters and compilers by taking interpreted code and compiling it at run-time.

2. PB in fact, is NOT an "optimizing compiler." It is a one-pass compiler that tosses in a few simple inline optimizations as it compiles--a very FAR cry from "a lot of optimizations". It is true (according to Fred) that the PB libraries are optimized by a C compiler, but the code WE (i.e. you and I) write has very little optimization (or perhaps, none, depending upon the code). Fred wrote the compiler to compile fast, not to generate optimized code. That is fine if you write code that is very library-dependent, but it can begin to show when it is mostly "original" code.

[DarkDragon]

No, every compiler is translating to ASM or directly to machine code.
...
Because compilers do a lot of optimizations.
...

Thorium, these statements can be a little misleading to newbies, for a couple reasons.

1. The term "compiler" has become standard use for Java these days, too, and Java does NOT translate to asm or machine code; it translates to bytecode, which is then later translated to fit the machine it is executed on. I know, this is splitting hairs, but I thought it worth saying. Java has really blurred the line between interpreters and compilers by taking interpreted code and compiling it at run-time.

Thorium said, a compiler is translating to ASM or directly to machine code and the Java-VM itself has to be seen as a "machine", a virtual machine. The bytecode is equal to a machine code .. its just interpreted virtually by a virtual machine. So I don't know the problem with his statement.

[Tenaja]

Thorium said, a compiler is translating to ASM or directly to machine code and the Java-VM itself has to be seen as a "machine", a virtual machine. The bytecode is equal to a machine code .. its just interpreted virtually by a virtual machine. So I don't know the problem with his statement.

A virtual machine is just another name for an interpreter. They use that term to avoid the stigma with slow interpreters, since they use run-time compilation to set it apart. If it was just another virtual machine, it would not do run-time compilation.

edit:

...and besides, the "technical definition" of a compiler does not require it to output asm code; the "technical definition" is that it outputs a "different language", which can be another high level language--but most frequently, is asm.

[DarkDragon]

Thorium said, a compiler is translating to ASM or directly to machine code and the Java-VM itself has to be seen as a "machine", a virtual machine. The bytecode is equal to a machine code .. its just interpreted virtually by a virtual machine. So I don't know the problem with his statement.

A virtual machine is just another name for an interpreter.

Yes, a bytecode interpreter. This implicates bytecode is machine code of virtual machines.

...and besides, the "technical definition" of a compiler does not require it to output asm code; the "technical definition" is that it outputs a "different language", which can be another high level language--but most frequently, is asm.

Yes, there you're right.

[electrochrisso]

I think what this is boiling down to is, if you want to easily and quickly write, reasonably fast and efficient software, use PB, else if you want to write a bowl full of a tangled mess of spaghetti, use C++.

[TI-994A]

...so the direct translation of the optimized BASIC code (who must obey to some specific language constrains) can be less optimized (for the same something) than the same code rewrote using ASM from scratch...

...So the code generated (even if not highly optimized) can be well organized by hand in advance by the compiler author to a large extent. So there is some kind of balance. It's good code for a compiler, a little bloated compared to hand written ASM, and almost never fast as ASM...

Hi luis, and thank you for the elaborate answer; some very important points to consider.

In any case, since we're talking about PureBasic, the emphasis should be on its capabilities. We know that PureBasic is a single-pass compiler that performs a one-to-one conversion of our BASIC syntax code to Assembly without any optimizations whatsoever. This is then compiled into the final executable by FASM, which we know only optimizes for size. In the end, it is actually up to the PureBasic programmer to produce efficient code.

Which brings us back to the original question: Would it be fair to say that well-written and optimized PureBasic code would be translated into optimized Assembly code, and ultimately compiled into efficient executables? And by well written and optimized I mean tight and efficiently structured PureBasic code, with a smooth and systematic program flow, economical and effective use of memory resources, properly planned error and exception handling, etc. Would such a program be efficiently translated and compiled, or does PureBasic and FASM actually add drag and bloat to the final product?

I'm a little confused when you said "direct translation of the optimized BASIC code ... can be less optimized," and "it's good code for a compiler, a little bloated compared to hand written ASM."

I think what this is boiling down to is, if you want to easily and quickly write, reasonably fast and efficient software, use PB, else if you want to write a bowl full of a tangled mess of spaghetti, use C++.

Nicely put!

[luis]

We know that PureBasic is a single-pass compiler that performs a one-to-one conversion of our BASIC syntax code to Assembly without any optimizations whatsoever.

Actually Fred said use some kind of peephole optimization. That means before emitting the code, every small set of instructions is inspected to see if it's possible to replace for example a batch of instructions with less instructions (size) or more instructions requiring less execution time (speed). The limit is the small window of instructions inspected every time. So there is some modest optimization involved.

An example of a tiny little optimization another compiler could make but would probably require a different approach is this (even if this can be actually generated this way from start).

Would such a program be efficiently translated and compiled, or does PureBasic and FASM actually add drag and bloat to the final product?

My answer is still the same. No compared to hand written ASM. For a compiler is subjective, especially since we don't have other compilers for the same language to make a comparison. I'm perfectly happy with it, and as I said the fact PB is a more rigid and predictable language compared to others helps when generating the code IMHO. Anyway from time to time some bugs about wrong code generated from valid PB source still creep in, so it's a little premature to think about further optimizations to be introduced at this stage. BTW there is still the fact some unused procedure are compiled in the final exe, if we want to consider the "size" side of things.

I'm a little confused when you said "direct translation of the optimized BASIC code ... can be less optimized," and "it's good code for a compiler, a little bloated compared to hand written ASM."

1) the way you code in PB is determined by the instructions set provided (the keywords) and is guided in some way by the available libraries too. The code you write in PB can be great PB code, but sometime you could have written it in a total different way in hand-made ASM, so it's not a guarantee optimized code in PB can give the best optimized ASM code for that specific problem. Hand written ASM using a different approach could be better.

2) I'm happy with the code generated by the compiler, but it will always be "bloated" compared to hand written ASM because it's not so smart to see some redundant code could be avoided or some parameter can be passed in a more efficient way using a free register or other things like that. This is common to any compiler. The most astute compiler cannot beat the average ASM programmer in the way the general code layout is generated, unless we are talking of very small code.

[TI-994A]

Actually Fred said use some kind of peephole optimization ...

Even the slightest optimization is still good news. Thanks for pointing that out, luis.

... there is still the fact some unused procedure are compiled in the final exe, if we want to consider the "size" side of things...

Knowing that PureBasic is a single-pass compiler, bloat caused by the failure to remove unused variables/constants/procedures/etc. is the programmer's fault. A good programmer should not only be able to code well, but should also know the capabilities and limitations of the tools and resources he uses.

... The code you write in PB can be great PB code, but sometime you could have written it in a total different way in hand-made ASM, so it's not a guarantee optimized code in PB can give the best optimized ASM code for that specific problem. Hand written ASM using a different approach could be better ... the code generated by the compiler, but it will always be "bloated" compared to hand written ASM ... The most astute compiler cannot beat the average ASM programmer in the way the general code layout is generated ...

It would be highly unfair to compare PureBasic-generated Assembly with manually-coded Assembly; automated translations will invariably be less efficient than manual ones, and that's true for all compilers. But still, the important thing is that PureBasic and FASM does not worsen your code. It all comes down to the programmer; if you write good, clean code, PureBasic would be able to produce fairly decent and efficient executables. If you don't, no amount of manual Assembly-tweaking, and no optimizer in the world would be able to help you.

Thank you for taking the time to explain the intricacies to me; your points directed me to some good resources in the forum, which have clarified my concerns.

[Tenaja]

Knowing that PureBasic is a single-pass compiler, bloat caused by the failure to remove unused variables/constants/procedures/etc. is the programmer's fault. A good programmer should not only be able to code well, but should also know the capabilities and limitations of the tools and resources he uses.

Actually, because PB turns every Procedure into a macro, it can test for its use at the end and not include the macro if the proc was never called. I think it is a neat trick to eliminate procs that are never called--Kudos to Fred! (If only he applied that technique to variables! BTW, constants do not consume memory, so they are less important, just bloat on the code side.)

A perfect example of taking advantage of this feature is if you want to generate, say, a free version and a paid version; you can leave all of the code in but just a single compilerif to skip the call to the paid feature. Conveniently, PB omits the uncalled procs in the free version, making it impossible to "undo" the crippling. It could be laborious to segment each and every extra proc within the code, but since we can do a quick & easy conditional compilation just around the call (for instance, in menu handling), Freds method of unused-proc removal eliminates a lot of hassle for us.

But regarding it being the "programmers fault" if there could be unused procs...well, you could apply that "blame" to every construct that is less efficient than asm. It turns into a slippery slope ending in "all good programmers use asm." After all, isn't that why we use PB (or any other high level compiler) instead of asm--so we don't have to do things the compiler can easily take care of for us?

[TI-994A]

Actually, because PB turns every Procedure into a macro, it can test for its use at the end and not include the macro if the proc was never called...

Hi Tenaja; thank you for pointing out yet another interesting PureBasic feature.

But regarding it being the "programmers fault" if there could be unused procs...well, you could apply that "blame" to every construct that is less efficient than asm. It turns into a slippery slope ending in "all good programmers use asm." After all, isn't that why we use PB (or any other high level compiler) instead of asm--so we don't have to do things the compiler can easily take care of for us?

It's always the programmer's fault if it is something within his ability to do; but coding in Assembly isn't exactly within the reach of the average PureBasic programmer. Even the best compilers can only do so much.

[Tenaja]

It's always the programmer's fault if it is something within his ability to do; but coding in Assembly isn't exactly within the reach of the average PureBasic programmer. Even the best compilers can only do so much.

I would venture to guess that "very good" code is also not within the reach of the average programmer! (PB or not!)