flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Heap > HLL compilers generate better code than hand written asm?

Goto page Previous  1, 2, 3, 4, 5, 6, 7
Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15241
Location: 1I/ʻOumuamua
Hehe.

I just watched the switches presentation from OOTB: https://millcomputing.com/docs/switches/

If you have the time skip to 01:19:08 in the video (the postscript) where Ivan makes a confession about the compilers. Laughing

The actual confession is at 01:19:37: "The compiler would not find this." Laughing Laughing when referring to a piece of hand optimised code that is only two-thirds of the length of the compiler generated code.
Post 23 Oct 2017, 15:52
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3459
Location: Bulgaria
Very Happy
Post 23 Oct 2017, 17:41
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 868

revolution wrote:
If you have the time skip to 01:19:08 in the video (the postscript) where Ivan makes a confession about the compilers. Laughing

The actual confession is at 01:19:37: "The compiler would not find this." Laughing Laughing when referring to a piece of hand optimised code that is only two-thirds of the length of the compiler generated code.

Compilers will never be "the best" at code generation unless AI takes over and ditches some stupid maintainers. And it doesn't have to do with humans having special powers (though we are indeed great at abstract thinking to see problems outside the box). It has to do with compiler developers' attitudes.

I don't know how it is with other projects, but with GCC if someone sends a patch with a "super optimization" mode that provides smallish gains but increases compile-time significantly, it gets rejected (and it's pointless to try to defend the guy as I did). Which is pathetic, this way it will never improve, because some problems are difficult by definition.

Who the fuck prioritizes compile-time speed for FINAL SUPER OPTIMIZATION compilation? Compiler maintainers. That's why compilers will always be behind human-coded assembly (of course, assuming you even hand-code in asm). If you want compilers to move forward, make them work really hard for a 1% gain. Much of the easy optimizations are already mature but they won't see it.

I don't care how much they want to favor stupid compilation speed (Rolling Eyes), I want a switch even if it makes compilation take from 15minutes to 6 hours (I'll do it overnight), even if it's just 1% gain. Because then I know compilers won't be held back by moronic attitudes.


On a sidenote, that architecture looks really hard-coded, even more than Itanium, exposing way too much of itself to the software. Yeah, I get it, this keeps it simple to decode and makes it fast and stuff, but then it will be difficult to extend it properly (since no abstractions) without breaking all software written for it.

I'm not even talking about extending the instruction set btw. I mean extending the actual micro-architecture (pipeline length, execution units, and so on) that's mostly hidden in x86 for example.
Post 23 Oct 2017, 20:30
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15241
Location: 1I/ʻOumuamua

Furs wrote:
On a sidenote, that architecture looks really hard-coded, even more than Itanium, exposing way too much of itself to the software. Yeah, I get it, this keeps it simple to decode and makes it fast and stuff, but then it will be difficult to extend it properly (since no abstractions) without breaking all software written for it.

You have to watch the other videos to learn about the "specialiser" which does exactly that job of dealing with different resource sets and how that is handled.
Post 24 Oct 2017, 00:56
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15241
Location: 1I/ʻOumuamua

Furs wrote:
I want a switch even if it makes compilation take from 15minutes to 6 hours (I'll do it overnight), even if it's just 1% gain.


Code:
gcc foo.c -Oinsanecrazywearoutyourfanburnyourcpustaketheweekendoff

GCCCompilation completed in 71:36:54.934
GCCSaved 0.0034% execution time.
GCCThis code needs to run 29,412 times longer than 71:36:54.934 to realise any overall gain in production.
GCCNoteyou need to compile this again if you change any part of the architecture in the future.

Wink
Post 24 Oct 2017, 03:45
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3459
Location: Bulgaria
The super optimization compiler will never beat human, not because of the compiler itself. The source code is the problem. The super optimized HLL source code is very hard to be written.

Actually, HLL programmer solves the problem: "What source code to write in order to get the optimal assembly code". In result:

1. If he knows the optimal assembly code, he probably made some tests and have the assembly code already. Why to write HLL code then?

2. Such HLL code is often much less readable and hard for understanding/maintenance. Often, more than the assembly code.

3. Such HLL code is optimal only for particular architecture.

That is why the programmers does not write optimal HLL code, except for the very critical small parts of their programs and I can't see how this can be changed in the future.

In the years I took part in several C vs ASM battles, where the task was not a particular algorithm, but complex enough program. It was permitted to make several versions, incrementally improving the solution.

So, the first versions of the assembly code (my) were very far from optimal, but still from 10 to 80 times faster than the C++ solution. In the next versions, I incrementally accelerated my solution 2..4 times. The C++ programmer started to copy my code one-by-one and translate it to C++. This way he was able to end with code only 10..20% slower (which is great), but totally unreadable and not portable C++ code. In the same time, my code remained readable, well structured and later used it for other projects with minimal changes.
Post 24 Oct 2017, 04:21
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 868
@revolution: Laughing but of course I meant more realistic in the sense that a human could definitely "optimize" better. If it takes a human to manually optimize something in 6 hours I don't see why GCC wouldn't be able to do similar in 6 hours, provided the source code provides all the necessary information (for example, using "restrict" properly). Obviously it has to be coded to even attempt to do that... and you know what that means. (that's what I meant with AIs, not necessarily "more intelligent beings than humans" at all, but simply "willingness to make such a super optimization mode where all the slow algorithms that were discarded get used")

@JohnFound: yeah, I agree about the part where the source code matters. In particular, the source code must give sufficient information to the compiler about the intent.

Otherwise it is literally impossible for it to know/prove that, say, two memory operands don't alias. That's why things like "restrict" exist (there's more but those are GCC extensions...) to "hint" the compiler about the intent. Of course, if you're wrong about them, the generated code will not do what you expect. Not the compiler's fault though, since you told it they won't alias (if they do, it's your fault).
Post 24 Oct 2017, 17:34
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15241
Location: 1I/ʻOumuamua
So to summarise:

Compilers have to guess what is required. Humans already know what is required. And thus the divide can never be closed due to compilers dealing with insufficient input information.

Waah, we need AIs that can understand the requirements.

Compiler, do what I mean, not what I say.
Post 25 Oct 2017, 05:42
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 868
Well compilers have to guess what is required because most HLLs suck and don't provide enough information (rather, don't allow you to provide enough information). Sadly even C/C++ lack a lot of this, however it's more bearable with GNU extensions.

The simplest (without talking about aliasing) is something like an "assume" directive. Tell the compiler something is assumed to be a value or relative to another etc (even if it doesn't do anything currently, it should still be there in the language).

MSVC and GNU both provide a "means" of doing this, but they're obviously not taking full advantage of it. However, it does turn a theoretically impossible situation into a possible one so the ball's on the compiler developers' court now to actually implement it properly, not on the language's lack of ability to inform it. But most other HLLs than C/C++ don't have many extensions and there's plenty still missing that would help the compiler "understand" your code, sadly.

Of course during debugging builds you turn the assume into an assert to make sure it's not invalid and assumed wrong (else subtle bugs will creep Smile).
Post 25 Oct 2017, 12:21
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5, 6, 7

< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.