flat assembler
Message board for the users of flat assembler.

Index > Heap > Assembly optimization is Compiler's job

Goto page 1, 2  Next

Do you agree?
Yes.
53%
 53%  [ 8 ]
No.
46%
 46%  [ 7 ]
Total Votes : 15

Author
Thread Post new topic Reply to topic
0.1



Joined: 24 Jul 2007
Posts: 474
Location: India
0.1
Assembly optimization of HLLs is a Compiler's job and we should not
be bothered by it!

_________________
Code:
 o__=-
 )
(\
 /\  
    
Post 30 Jul 2007, 08:32
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
of course, who else should do it in case of HLLs?
Post 30 Jul 2007, 09:14
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
0.1



Joined: 24 Jul 2007
Posts: 474
Location: India
0.1
Some people insist on rewriting the part of HLL code to gain efficiency!
Post 30 Jul 2007, 09:15
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
If there's significant gains to be had (ie., you can utilize MMX/SSE), and it makes sense for your application, by all means handcode it in assembly.

Compilers are pretty decent these days and you don't need assembly for most application types (and that's been true for several years), but there's still plenty of situations where it matters. And of course machine architecture knowledge helps even when writing HLL code...
Post 30 Jul 2007, 14:36
View user's profile Send private message Visit poster's website Reply with quote
0.1



Joined: 24 Jul 2007
Posts: 474
Location: India
0.1
Yeah that's exactly my concern: why can't a compiler itself use MMX/SSE?
Post 30 Jul 2007, 14:46
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
as you worded it:
Quote:
Assembly optimization of HLLs is a Compiler's job and we should not be bothered by it!


I agree, you won't optimize significantly better, you can get few extra cycles from it, but that seldom matters.

You can sometimes write completely new code in assembly (not optimize HLL code), that uses things that can't be done in HLL (like MMX/SSE, SMC, ...), and get more significant speedup.
Post 30 Jul 2007, 15:00
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2141
Location: Estonia
Madis731
I won't answer to these kinds of questions 'yes'. Not now and not in the near future. I think that any kind of optimization low- or high-level should be done be a person unless compilers start using NNs and profile their own 'work-of-art' and developing in succession.

The optimizations compilers do these days, are made by people and can be rewritten by other genius people. Smile

HLL is nearly the point where I crack, but I still answered 'no' Very Happy
Post 30 Jul 2007, 17:02
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
wrote:

The optimizations compilers do these days, are made by people and can be rewritten by other genius people. Smile

Of course, their optimizations aren't better than the people who wrote the optimization engine, etc etc. Point is that for most code it doesn't matter, and for the code that does matter, even JAVA and dotNET allows you to link with native assembly code. It's a win-win situation Smile
Post 31 Jul 2007, 00:21
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Madis731 wrote:
I think that any kind of optimization low- or high-level should be done be a person unless compilers start using NNs and profile their own 'work-of-art' and developing in succession.

The optimizations compilers do these days, are made by people and can be rewritten by other genius people. Smile

HLL is nearly the point where I crack, but I still answered 'no' Very Happy


I agree. I program in assembly because i don't like the kind of work the machine does with my code. If i have a style i want it to show in the program, not just the source. If i have a few ideas on how things should be done, i want to be able to do it without the compiler bitching about type casting and things like that. I know what i'm doing, but the compiler insults me and tells me that i don't. Also, the compiler dosn't know when to optimize a section for speed or for space.
Post 31 Jul 2007, 00:23
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
kohlrak wrote:

without the compiler bitching about type casting and things like that. I know what i'm doing, but the compiler insults me and tells me that i don't.

If your compiler bitches about type casts (and you're not dealing with the win32 API or similar legacy and ill-constructed code), you frankly don't know what you're doing... clean code doesn't need typecasts except for a very few places.

kohlrak wrote:

Also, the compiler dosn't know when to optimize a section for speed or for space.

It has it's heuristics, and most (C++) compilers support setting those optimization switches at least at file level... which is usually fine enough if you design your stuff properly. Other compilers support changing the optimization options with #pragma statements within a source module.

Sure, you don't get the level of flexibility that assembly brings you, but the point with HLLs kinda are to focus on the overview and not get lost in the details... too many assembly programmers end up obsessing about how to optimize their wndprocs, which (while humorous to watch) simply does not matter.
Post 31 Jul 2007, 00:30
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:

Of course, their optimizations aren't better than the people who wrote the optimization engine, etc etc.

However, we have to remember that the cognitive capacity of the human being isn't very big while the computer running the proper algorithms has no problem in handling lots of information at the same time. This means then, that in some situations the creation can outperform the creator Very Happy
Post 31 Jul 2007, 00:47
View user's profile Send private message Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
If your compiler bitches about type casts (and you're not dealing with the win32 API or similar legacy and ill-constructed code), you frankly don't know what you're doing... clean code doesn't need typecasts except for a very few places.


Let's say you wanted to operate on 4 letters with one operation? Well, in assembly you can simply treat the array of characters as an array of ints. Not so easy in HLLs.

Quote:
Sure, you don't get the level of flexibility that assembly brings you, but the point with HLLs kinda are to focus on the overview and not get lost in the details... too many assembly programmers end up obsessing about how to optimize their wndprocs, which (while humorous to watch) simply does not matter.


Optimized wndproc... now *that* is an oxymoron... I actually found a technique that it seems not everyone uses to speed up the wndproc, but it's not even worth mentioning to those who don't, since it's not only common sence, but wndproc seems to be put on a delayeed usage timer anyway. As long as you don't have a loop running in it or layered attributes, it could be the worst section of code you've ever seen and it still wouldn't hinder any exturnal programs. The worst you can do is delay how long it takes for the program to close after the main window has been shot down since the window itself seems to be run in a seperate thread. Infact, it's so pointless, i don't even use the technique. That'd be like trying to optimize a drawing function for OpenGL. You're not going to escape using the FPU and that'll probably be your greatest performance hit there...
Post 31 Jul 2007, 00:56
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
MichaelH



Joined: 03 May 2005
Posts: 402
MichaelH
Funny, it seems only a few months back I was explaining the very basics of programming to kohlrak on things like how to debug an app, how to convert C++ code to assembler using Visual C++ etc ..... how time flies ...... hang on, it was only a few months ago Shocked
Is it really only me that gets annoyed at this #$%&#$@'s ego stinking up every thread at this forum?
Post 31 Jul 2007, 02:09
View user's profile Send private message Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
speaking of ego...
Post 31 Jul 2007, 06:24
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
kohlrak wrote:
Also, the compiler dosn't know when to optimize a section for speed or for space.


I must be misunderstanding this because compilers do know how to do this (to some limited degree).

OpenWatcom by default targets both size and speed (-os optimizes for space, -ot optimizes for time, and -ox is maximum optimization).

Old old GCC versions supposedly had to use -O2 while we now are able to use -Os for smallest size. (Yes, there's still room for improvement.)
Post 31 Jul 2007, 07:33
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
OpenWatcom by default targets both size and speed (-os optimizes for space, -ot optimizes for time, and -ox is maximum optimization).


In the middle of your code?

I think the biggest point of those against compilers remains that decent optimization takes creativity, something that the compiler lacks. What really annoys me more than that is the limited operation of some of these HLLs. You have your datatype issues (i think my 4 bytes [4 characters] being treated as an int [dword] for speed example is adequet explanation) and lack of operators (without inline asm; the lack of these operators make you use abstract ways of producing the same result, and the compiler dosn't recognize your usage of that abstract method is for something that's in the instruction set) make HLLs a little optimization un-friendly. But, they enable inline assembly in them for a reason.
Post 31 Jul 2007, 08:30
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> there's still room for improvement.

Size of BGCC itself Laughing

> why can't a compiler itself use MMX/SSE?

Faulty compilers do Shocked

Illegal instruction exception occurred at C763:34783FFF ... please upgrade your CPU

I prefer good 80386 compatible assembly from output of compilers "supporting" SSSSEE 4.3 Sad
Post 31 Jul 2007, 08:50
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
rugxulo wrote:

Old old GCC versions supposedly had to use -O2 while we now are able to use -Os for smallest size. (Yes, there's still room for improvement.)

GCC offers a lot more switches than that, for very specific tweaking contol... thing is, sometimes it ends up producing worse code than simply "optimize of speed" or "optimize by size" Smile

kohlrak wrote:

In the middle of your code?

Some compilers do, yes. But usually per-module optimization settings suffice.

kohlrak wrote:

You have your datatype issues (i think my 4 bytes [4 characters] being treated as an int [dword] for speed example is adequet explanation) and lack of operators (without inline asm; the lack of these operators make you use abstract ways of producing the same result, and the compiler dosn't recognize your usage of that abstract method is for something that's in the instruction set)


Oh really?
Code:
size_t get_zts_length(const char *zts)
{
        const char *start = zts;
    unsigned int magic, alignment = (unsigned int)zts & 3;
  while(alignment--) if(!*zts++) return zts - 1 - start;
      zts -= 4;
   while(true)
 {
              magic = *(unsigned int *)(zts += 4);
                magic = (magic ^ 0xffffffff) ^ (magic + 0x7efefeff);
                if(magic & 0x81010100) break;
   }

  magic = *(unsigned int *)zts;
       if(!(magic & 0xff)) return zts - start;
 if(!(magic & 0xff00)) return zts + 1 - start;
   if(!(magic & 0xff0000)) return zts + 2 - start;
 return zts + 3 - start;
}
    


I'm not too fond of inline assembly, usually imho if something's worth writing in assembly, it's enough that it's worth doing in an external .asm file - easier to use with different compilers too.

0.1 wrote:

Yeah that's exactly my concern: why can't a compiler itself use MMX/SSE?

They can, but they're still not super-good at doing it, so you're better off writing MMX/SSE code manually. Even when the compiler has intrinsic support.
Post 31 Jul 2007, 13:48
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
Oh really?


Odd, it didn't complain this time. I would switch to a less buggy compiler, but i don't have a usage for one outside of compiling C/C++ tutorials to make sure they work and to re-organize them in a format more to my liking then convert. Still, the compiler still can't tell that using a loop and a store variable means left rotate or right rotate.

Quote:
Some compilers do, yes. But usually per-module optimization settings suffice.


That dosn't sound too fun...

Quote:
I'm not too fond of inline assembly, usually imho if something's worth writing in assembly, it's enough that it's worth doing in an external .asm file - easier to use with different compilers too.


Would be nice, but then you have to worry about making a compatable lib file... Still havn't been able to get a Visual Studio compatable lib file... then again, i havn't been trying too hard.
Post 31 Jul 2007, 21:25
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
Odd, it didn't complain this time. I would switch to a less buggy compiler

i wouldn't be so sure that problem was compiler Razz

Quote:
Quote:
Some compilers do, yes. But usually per-module optimization settings suffice.

That dosn't sound too fun...

Yet it is fun, having clean sources. You could give it a try, and create some bigger "modular" project.

Quote:
Would be nice, but then you have to worry about making a compatable lib file... Still havn't been able to get a Visual Studio compatable lib file...
i suppose "compatable" means "compatible". No, you don't need .LIB file. You need just plain .obj file. And you don't need even Visual Studio, all you need is Visual C/C++ compiler suite.
Post 31 Jul 2007, 22:23
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< 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


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.