flat assembler
Message board for the users of flat assembler.

Index > Heap > HLLs suck!

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Author
Thread Post new topic Reply to topic
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
f0dder wrote:
Azu wrote:
Azu wrote:
Unless it's unreadable memory and triggers an exception.. but what would be the point of that? Why not just put a jmp there to whatever code you wanted ran?
Perhaps you need the exception unwinding mechanism to kick in, perhaps you're doing it to obfuscate your code - plenty of reasons.
int3

f0dder wrote:
Also, you seem to completely ignore the memory-mapped I/O part.
Wouldn't you actually use the result in that case?

_________________
Post 02 Dec 2009, 00:46
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Perhaps you'd need the value, perhaps the read itself triggers hardware state change. And perhaps you're just trying to pre-touch pages without resorting to assembly or "really tricky dancing-around-the-optimizer" code.
Post 02 Dec 2009, 01:03
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
But that printf call trashes the value.

And isn't the whole point of HLLs to make hardware independent code? Otherwise use the little inline assembler thing.
Post 02 Dec 2009, 01:15
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Why use inline assembly if you can keep your entire codebase in pure C/C++? Inline assembly has different syntax across compilers, and some don't support it at all (VC++ doing 64bit builds, for instance). As for hardware independent code, sure thing, that's one of the points of HLLs - I'm sure you can find a lot of device driver code in pure C that works on a wide range of architectures Smile
Post 02 Dec 2009, 01:23
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
o.0

HLLs don't even properly support 64bit yet? Wow. So if you want to use an assembly optimized function and take advantage of decade old hardware (pretty much all CPUs made in the past decade are 64bit), HLLs still aren't ready yet? That sucks.


Do all HLLs have this limitation or just Microsoft C++?

_________________
Post 02 Dec 2009, 01:28
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
I don't really miss inline assembly.

It's compiler-specific, which is a bad thing... and whenever I need to write assembly code, it's usually enough code that I prefer writing it as an external assembly module anyway - which means I can use FASM, and not have compiler-specific code in my c/c++.

If you don't mind compiler-specific, there's intrinsic functions stuff like MMX and SSE, which has the benefit of the compiler doing register allocation for you. Doesn't beat hand-written assembly (well, last time I used SSE intrinsics was in 2003, thing have probably improved at least a bit), but lets you prototype your ideas before moving to a full from-scratch assembly implementation of your hotspots.
Post 02 Dec 2009, 01:34
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
f0dder wrote:
I don't really miss inline assembly.

It's compiler-specific, which is a bad thing... and whenever I need to write assembly code, it's usually enough code that I prefer writing it as an external assembly module anyway - which means I can use FASM, and not have compiler-specific code in my c/c++.

If you don't mind compiler-specific, there's intrinsic functions stuff like MMX and SSE, which has the benefit of the compiler doing register allocation for you. Doesn't beat hand-written assembly (well, last time I used SSE intrinsics was in 2003, thing have probably improved at least a bit), but lets you prototype your ideas before moving to a full from-scratch assembly implementation of your hotspots.

.......
Shocked
Image



MSDN wrote:
_m128 _mm_add_ss(__m128 a , __m128 b );
_mm_extract_si64, _mm_extracti_si64

_mm_insert_si64, _mm_inserti_si64

_mm_stream_sd

_mm_stream_ss

The holy ASM mnemonics have been corrupted!
Image











I don't wanna learn anymore about HLLs :< bye thread.

_________________
Post 02 Dec 2009, 01:37
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Yes, if you don't mind being compiler-specific, you have an alternative to inline assembly. I personally prefer the external asm modules, though, but people's mileage may vary.

And sure thing, the intrinsic names are long - if you don't like that, there's #define Smile
Post 02 Dec 2009, 01:42
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
f0dder wrote:
Yes, if you don't mind being compiler-specific, you have an alternative to inline assembly. I personally prefer the external asm modules, though, but people's mileage may vary.

And sure thing, the intrinsic names are long - if you don't like that, there's #define Smile


What happened to you, f0dder? Was it that long ago that you said my opinions about optimization didn't matter because they were insignificant and that we should use inline asm instead?
Post 02 Dec 2009, 22:08
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
Hmm?

I've been against "write everything in assembly" for quite a while, since it's - in my opinion - utterly useless and has been for more than a decade. Doesn't mean I'm against assembly or optimizations, though. Can't recall advocating inline assembly though, it's a long time since I dropped it in favor of external assembly modules.
Post 02 Dec 2009, 23:55
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
Hm, strange. I recall wonder why you even liked fasm because i felt you were such a big advocate that anything and everything (except anything already incredibly small) should've been written in C/C++ with inline assembly for any optimizations. Eh, maybe i was just wrongfully making an ASS out of yoU and ME. Embarassed
Post 03 Dec 2009, 01:04
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
Nah, I advocate using the right tool for the job - whether that be assembly, c++, python, java, c#, php or something else. My favorite is c++ for a variety of reasons, and I do sometimes end up using it where another language might be a bit more suitable Smile

Also, I'm against the idea that anything that isn't 100% hand-optimized to death is "bloated shit code", and I feel it's pretty much a waste of time obsessing about code that isn't a performance hot-spot. Doesn't mean it can't be fun or rewarding to obsess about a piece of code, it's the notion that "OMG! THERE'S A SUPERFLUOUS INSTRUCTION! THIS IS SHIT CODE!" I find (more than) silly.
Post 03 Dec 2009, 10:34
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
f0dder wrote:
Nah, I advocate using the right tool for the job - whether that be assembly, c++, python, java, c#, php or something else. My favorite is c++ for a variety of reasons, and I do sometimes end up using it where another language might be a bit more suitable Smile


Well, the real question always comes down to "what is the right tool?" To be honest though, despite C++ being my first language, i prefer to use asm for non-released projects, projects that i don't care who does or does not use, and projects i only ever intend to release for a specific setup or group anyway. But, to everyone their own, eh?

Quote:
Also, I'm against the idea that anything that isn't 100% hand-optimized to death is "bloated shit code", and I feel it's pretty much a waste of time obsessing about code that isn't a performance hot-spot. Doesn't mean it can't be fun or rewarding to obsess about a piece of code, it's the notion that "OMG! THERE'S A SUPERFLUOUS INSTRUCTION! THIS IS SHIT CODE!" I find (more than) silly.


Well, anyone who thinks that will go nuts if they look at the assembler. Any such person should be reminded that perfect optimization is impossible, because of microcode varying speeds not only between processors of the same family, but revisions of a processor too. I still remember some code I had working on my windows xp with a p4, and not working on the windows xp computers my school had which also used p4s. The problem was that i felt that the finit instruction was extra typing and extra work for the computer since if it worked on my computer and another computer, it must work on others. Especially because if there were to be race conditions due to uninitialized registers, i'd be absolutely sure to find them with all the programs i ran while coding in windows. Laughing

I do believe, however, that simply because a program runs fast enough to fare well on it's own does not mean it need not be optimized. I can imagine that I could find some code that would run awesome on a Phenom II and therefore pass the test, but it would be a real dog on a p3. To say that it's stupid to optimize because no one uses a p3 anymore would be laziness at best. If i've ever come across as a zealot, misunderstand me not. I'm only against negligence (people simply too lazy to optimize and/or fix bugs) and waste (by "waste," i mean things that are extra work for the programmer and are still slow, and they don't really add any benefit when plain and simple documentation would suffice [mostly, making a function over-robust]).
Post 03 Dec 2009, 11:16
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:
Well, the real question always comes down to "what is the right tool?" To be honest though, despite C++ being my first language, i prefer to use asm for non-released projects, projects that i don't care who does or does not use, and projects i only ever intend to release for a specific setup or group anyway. But, to everyone their own, eh?
Sure thing - as long as you realize that personal preference doesn't mean that "it's the only right way to do things and everything else sucks"... not saying you suffer from that, but a lot of people do (and that goes for low-level as well as high-level fans - there's blind zealots everywhere).

kohlrak wrote:
Any such person should be reminded that perfect optimization is impossible, because of microcode varying speeds not only between processors of the same family, but revisions of a processor too.
Sure thing - and some optimizations can penalize other architectures a lot. But you can strive to do a good "blended" optimization, or provide some per-cpu optimizations and select at runtime. Once again, what makes most sense depends on the code problem you're trying to solve.

kohlrak wrote:
I do believe, however, that simply because a program runs fast enough to fare well on it's own does not mean it need not be optimized. I can imagine that I could find some code that would run awesome on a Phenom II and therefore pass the test, but it would be a real dog on a p3.
This really does depend on what you're writing, why you're writing it, and the target audience. Don't get me wrong, I'm no fan of sloppy code, but for most real-life situation non-optimal code is good enough. It's not a problem that your code won't run on a 200MHz Pentium if your customers all have dualcore machines.

kohlrak wrote:
To say that it's stupid to optimize because no one uses a p3 anymore would be laziness at best.
Sure thing - and I like knowing that my code can run comfortably on older hardware than it has to. At the same time, I'm willing to trade an amount of performance for faster development and less time spent on uninteresting code parts, and I'll rather "waste" a few clock cycles on stack cookies and buffer-length validation than having a pzwn'd system.

Where to draw the line, for me, depends on the application. I don't like the fact that a generic thing like word processors has become as sloppy as they have - both OpenOffice and the later versions of MS Office are beasts. But a piece of specialized business app being a bit on the heavy end? Doesn't matter (apart from personal pride) if it won't work comfortably on a PIII if it's never going to run on anything but dualcore machines.
Post 03 Dec 2009, 12:01
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
Okay, I know I said I wasn't going to be in this topic anymore.. but come on.. you're not being fair, the code I was complaining about served no purpose. It definitely wasn't buffer-overflow protection, and nor would it have been inordinately hard to optimize out.

_________________
Post 03 Dec 2009, 12:11
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
The discussion d/evolved since that...

Anyway, yes, it's a superfluous instruction and it could certainly be optimized out - but at the same time, it's not exactly the end of the world, and claiming that "HLLs suck" because of such a minor detail is silly. The reason it's generated is probably that function pro/epilogue code is inserted as binary boiler-plate code, rather than "pcode" to be run through the optimizer.

But while VC2008 does generate this sub-optimal construct when generating stack frames, it does accumulate the "add esp, xx" when you're calling multiple cdecl functions (but I guess you'll find a reason to bitch about that as well Smile)
Post 03 Dec 2009, 12:54
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
Oops. I thought you were referring to me, sorry. Who were you referring to?
Post 03 Dec 2009, 12:57
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
This really does depend on what you're writing, why you're writing it, and the target audience. Don't get me wrong, I'm no fan of sloppy code, but for most real-life situation non-optimal code is good enough. It's not a problem that your code won't run on a 200MHz Pentium if your customers all have dualcore machines.


And if it's slow when threaded too? All too often I see a program that is slow where this is the excuse for it. The computer gaming industry is the greatest example of this. I can think of one game off the top of my head which is horribly slow, and i honestly can't think to why it is, despite being beautiful, it's not THAT beautiful. Interestingly enough, the game was a flop when the people who liked the series had so much trouble running it. (See "Star Trek: Legacy" by Bethesda.)

Quote:
Where to draw the line, for me, depends on the application. I don't like the fact that a generic thing like word processors has become as sloppy as they have - both OpenOffice and the later versions of MS Office are beasts. But a piece of specialized business app being a bit on the heavy end? Doesn't matter (apart from personal pride) if it won't work comfortably on a PIII if it's never going to run on anything but dualcore machines.


I gave my usual exaggurated example, but all too often do I hear an excuse that the customer supposedly will always be willing to upgrade, because parts (especially ram) is always cheap. Heck, someone I know is asking me how much it would cost to upgrade her computer, because bloated software that her school uses requires it. Her computer isn't the newest in the world, but there are still lots of people using Windows XP. True, specialized things may not need to be optimized, though some specialized things should be (especially for databases).

The problem is (and i said this years ago), all too often programmers (even new age ones) don't understand they're programming in a multi-process environment. They must consider what their audience is most likely to run along-side their programs. If your program is for digital timecards rather than using an old punchcard system, it could be as bloated as hell, and no one would care so long as they didn't wait longer than 5 seconds in line. The problem comes in when you're browsing and you get an instant message or something, but your movie player, which you've recently had up, is so bloated that the IM application got paged/swapped and you're waiting anywhere from 5 to 30 seconds (depending on hardware and the application itself) while it pops up, and if it's a fast talking person (common for most users), that person is going hog wild sending you anywhere from 5 to 10 messages whileso causing constant interrupting to the procedure of refreshing the screen.

Quote:
But while VC2008 does generate this sub-optimal construct when generating stack frames, it does accumulate the "add esp, xx" when you're calling multiple cdecl functions (but I guess you'll find a reason to bitch about that as well Smile)


I'll jump on it, too, actually, but not at VC2008, but at the programmers. All too often do programmers end up with these kinds of inefficiencies (and how horrible the compiler tends to be with function calls) thanks to excessive functioning. Some routines are called only once, and it's not the compiler's job to declare inline for them (I'm not saying you in particular suggest that, though). Really, people should learn how to use that...
Post 03 Dec 2009, 12:58
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
Games, well, dunno. Things have gotten a lot more complex than in the old days, physics and AI consumes a fair amount of CPU cycles. Geometry and textures have become pretty damn detailed, so it's hard to avoid large memory usage. Shaders are becoming increasingly complex as well. Could the games be more optimized? Very likely. Is it inevitable that higher detail means larger resource consumption? Yep. Is the resource consumption proportional with the "prettiness"? Not always.

kohlrak wrote:
I gave my usual exaggurated example, but all too often do I hear an excuse that the customer supposedly will always be willing to upgrade, because parts (especially ram) is always cheap.
Well, once again, I'm not a fan of sloppy software.

What I'm arguing is that there's a big difference between begin sub-optimal and outright sloppy.

kohlrak wrote:
True, specialized things may not need to be optimized, though some specialized things should be (especially for databases).
And here my point is: know what to optimize. If you're doing a database frontend, it's not going to matter one bit whether you're writing the frontend in assembly, C++ or Delphi, nor whether you use raw win32 API calls or some GUI toolkit - even for 10 years old hardware. What's going to matter is your data representation, your SQL statements (or ODBC calls), and whether you constantly pull stuff from the database that could be cached.

MSN Messenger is a good example of "ugh, wtf!" code. The current Live is really really bad, but even the previous version was bad - when I can type faster than the program can render text, things are bad (even though I'm a fast typer Smile). That was on a P4-1.7GHz-celeron running WinXP.

kohlrak wrote:
I'll jump on it, too, actually, but not at VC2008, but at the programmers. All too often do programmers end up with these kinds of inefficiencies (and how horrible the compiler tends to be with function calls) thanks to excessive functioning. Some routines are called only once, and it's not the compiler's job to declare inline for them (I'm not saying you in particular suggest that, though). Really, people should learn how to use that...
Well, I don't entire agree here. Splitting code in functions can help a lot with readability, and doesn't necessarily mean much performance-wise - especially with inlining and link-time code generation Smile
Post 03 Dec 2009, 14:55
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:
Games, well, dunno. Things have gotten a lot more complex than in the old days, physics and AI consumes a fair amount of CPU cycles. Geometry and textures have become pretty damn detailed, so it's hard to avoid large memory usage. Shaders are becoming increasingly complex as well. Could the games be more optimized? Very likely. Is it inevitable that higher detail means larger resource consumption? Yep. Is the resource consumption proportional with the "prettiness"? Not always.


That's pretty much my stance on them.

Quote:
Well, once again, I'm not a fan of sloppy software.

What I'm arguing is that there's a big difference between begin sub-optimal and outright sloppy.


I'm trying to bait you into descerning what that is. Laughing

Quote:
kohlrak wrote:
True, specialized things may not need to be optimized, though some specialized things should be (especially for databases).
And here my point is: know what to optimize. If you're doing a database frontend, it's not going to matter one bit whether you're writing the frontend in assembly, C++ or Delphi, nor whether you use raw win32 API calls or some GUI toolkit - even for 10 years old hardware. What's going to matter is your data representation, your SQL statements (or ODBC calls), and whether you constantly pull stuff from the database that could be cached.


Unfortunately, most people rely too much on other things (compiler and such) to handle that for them, despite that those thing won't do it for them. They see it runs fine enough on their dev machine (which, in many cases with bigger companies, tend to be much better than their client's pc) with no other programs running alongside it, then they release it as "faster and better" than a previous version.

Quote:
MSN Messenger is a good example of "ugh, wtf!" code. The current Live is really really bad, but even the previous version was bad - when I can type faster than the program can render text, things are bad (even though I'm a fast typer Smile). That was on a P4-1.7GHz-celeron running WinXP.


Ugh, i know what you mean. I have a problem like that every so often with pidgin, but before i accuse pidgin, i look around for any other programs that might be even more significantly slowing everything else down. Despite how bloated and buggy pidgin is, it's usually not the culprit. Though, it probably would help for them to go back through their code and tink around a bit trying to fix it up just a little... It's a little awkward that when getting a message from someone or irc or something (not even a third party plugin) results in the messenger just up and going poof on me. Honestly, they can't keep blaming third party plugins and other things all the time.

Quote:
kohlrak wrote:
I'll jump on it, too, actually, but not at VC2008, but at the programmers. All too often do programmers end up with these kinds of inefficiencies (and how horrible the compiler tends to be with function calls) thanks to excessive functioning. Some routines are called only once, and it's not the compiler's job to declare inline for them (I'm not saying you in particular suggest that, though). Really, people should learn how to use that...
Well, I don't entire agree here. Splitting code in functions can help a lot with readability, and doesn't necessarily mean much performance-wise - especially with inlining and link-time code generation Smile


Depends on how big the program is and how deep the calls go, really. If it goes deep enough, one could significantly waste time, especially in a loop (make a bunch of function calls at at least a depth of 10 in a loop, all because the coder is coding for their screen size). Also, i'm more fond of dynamic linking than static linking (i don't want to spend hours waiting for the install because they're afraid to use DLL files provided with windows).
Post 04 Dec 2009, 00:48
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger 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, 8  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.