Futuristic Barny (borg): I am you, you are me, we're co-lec-tive ent-ti-ties.

I'm sick of the HLL propoganda, though. They can go ahead and have their slow, imperfect coding language that also makes it harder to learn how to make your code faster (such as using a while instead of a for in C++ if you're doing a count that you can impliment to stop at 0). I'm just sick of them making us look like obcessed people with no life.

HLL propaganda? *shrug*

Most HLL coders I know chose their language of choice because it gets the job done faster than <insert other language>, or because there's some other advantage to it.

If you write code that needs to run on both 32- and 64-bit x86, assembly is already not the best choice. Once that code also needs to run on Itanium, PA-RISC, ARM/XSCALE, etc... then you don't really want to do it in assembly

For code that revolves around API calls (like most GUI stuff), you don't need assembly either - even a shitty compiler like PowerBASIC will not generate bad enough code that you can time problems.

How long have you been programming? Which languages, and for how long? Your previous post where you obsessed about irrelevant details, it would seem that you haven't used neither assembly nor a HLL for very long...

If you had, you'd probably also know that compilers can "turn a for loop into a while loop", and you'd know that not everybody writes retarded code

I've used C++ for about 2 years now. i'm still learning assembly. As for turning a for into a while... let's take teh following code...



The compiler dosn't know to turn that same code into the following...



Now i don't know for sure (i admit) that the latter one wouldn't need the sub or something to check if the condition is false or not.

Compilers, while some are pretty good, still aren't perfect. You're right with this pretty contrieved example - MSVC fails to do this particular reordering here, it probably doesn't like the counter dependancy.

I've seen it done for other (real world ) pieces of code, though. And oftens this either
A) won't matter
B) matters to the extremes, where you're better off doing assembly anyway

Kohlrak: Those are not equivalent - the first sums 0 to 99, the second sums 1 to 100.

lol, good eye goplat.

and the problem, fodder, is that we don't know how well the STL and things are coded to begin with. Too many people don't know about the "inline" keyword in C++, and i often forget it myself. And maybe it dosn't matter, and sometimes it does. In my personal opinion, if you pay for something it should be the best you can make it. So you have a large number of corperations using C++, and them all codding not only horribly, but using an impefect compiler, and with habits like theirs, they really could use every clock cycle that they can get. Especially if you're making a game and would like to clock about 60 FPS. Problem is that people aren't taught all the "nifty little tricks" of their nice HLLs, and to top it off the compiler isn't smart enough (and it shouldn't have to be) to make their algorithams better. In assembly you can get a pretty good idea just by looking at your code weather it'll be fast or slow. These HLLs, on the other hand, are a bit far from what the code actually looks like. People often like to beleive that since the compiler has "optimization features" that it'll be able to understand their program and do all the problem solving for them. One of the students in my C++ class in school claims microsoft made an A.I. program. Now i know many people like to make this claim with their software, but there is no such thing as artificial intellegence. It's either intellegent or it's not. Too many people don't know diddly squat about their computer.

In "real" (bussiness capitalistic sales management driven) world it's more like: "We can make it cheapiest and crappiest possible, if we can get paid for it"

Yes unfortunately thats true...
That is why even just general products are not built to last these days e.g.
my dad's old 17" Philips monitor bought way back 1994 lasted till two months ago. and what TFT monitors have a life expectancy of 3 years?

Cheers.

You use the STL to get the job done. If you end up with a speed or (memory) size bottlenecks, you research the problem, and possibly write your own algorithm/container/etc. STL implementations are generally pretty decent these days, but you can do better when you really need it; for instance I probably wouldn't use STL for the inner parts of a raytracer.


Most compilers ignore the "inline" keyword, so it's more a question of knowing where to put your functions. For very short ones that need inlining, they need to go in a header file. "Link-Time Code Generation" helps this somewhat, but it's still a good idea to keep the really short functions in headers.

And of course to think long and hard about program/class design, so you don't have too many necessary really-short functions.


You're not really CPU bound in games these days, you're largely GPU bound. Things like physics and AI is mainly what's done on the CPU, and those are relatively complex tasks - I dunno how much benefit you'd get from assembly-optimizing that, really.

You might want to check google, to see that even for GPU-bound games, optimizations are being done.

Now, if you look at the standard assembly code being churned out by people, lots of it is of pretty poor quality. See just about anything created by a MASM32 user, and the M32LIB in particular.


Wrong - "crappiest" is not part of the equation. It's "We'll ship it as fast and cheap as possible". Depending on company, this can mean crappy software... on the other hand, there's still companies that try to "get things right" - I think Blizzard has done pretty well.

you are unfortunately right about this. One of problems is for example, that new people are given bad practice. Almost no asm coder checks return values, etc. I am even pushing on tomasz now to add error handling to all examples

about the companies: i know only very little software that didn't bitch up with managementy things. And i don't know ANY new company which takes quality into account.

I have a simple rule... If it is used once, it dosn't go into a function. On the flip side, people are usually told to put big sections of code into functions, even if it's only used once. So the flip side needs to learn how to use the inline, if they're going to do that, so that the code will be at least a bit faster.



Well, first off, since they depend on each other you'll want to make whatever code that the GPU must execute (such as the algorithams to decode the models or images) you'll want to make that as small as you can (because from what i've heard, the GPU runs a bit slower than the regular processor) and even a slow calculation on the AI can be pretty laggy if you have a complex enough AI, and now people are getting more and more concerned with how "smart" their "ai" are.



Just enough to give the company a good outlook so the product sells. Let's not forget what some people THINK are optimizations, but really the opposit.



Just looking at the quality of the popular C++ classes, i could just imagin how poor the assembly information can be, since it is hard to get, we really can't get very picky with what we ask for. I find it alot easier to optimize in assembly than C++. When i think of the best way to do the calculations, i usually miss alot.



Keyword bolded and underlined, and even then. How hard are they trying?



Windows programmers are supposed to "program on the defencive." Whatever happened to that logic when making an API? I never made a DLL in assembly, but you better beleive that if i did i'd make sure that some sort of predictable return value was sent, weather it be an example of windows' troolean logic to tell if there were any problems or not. There's no excuse not to do this. Personally, i think that coders making things should also be a little more considerate about conservation of the registers. For instance, if you don't have a creative use for what you put in the registers other than eax, perhaps you should consider putting a warning, at least, that those registers are going to be edited.



Isn't that the truth... lol Sit in my computer class and you'd understand why. I try to make a habit of making my code as optimized as possible, even if i'll never use the program more than once. That way optimization becomes a habit and i can honestly say that all my programs are efficient. Yet, in my C++ class, we're not allowed to use things that we havn't covered yet, that includes things we'll never cover. Now, i could easily use alot of the binary operators to enhance the execution time very, very greatly. And these people will make a habit of NOT using them, because of this. Yea, his reasons are noble for saying some of the stuff we can't use until we've covered it, but stuff that we won't cover we should be able to use. I've noticed the bad habits are really rubbing off onto my C++ programs, and it's becomming hard to make my C++ programs as efficient as they were before i started taking the class. The problem is nobody knows what they're doing or talking about anymore, and, i'm sure by now you know this, that it's pretty bad when I am pointing that out.

That's why it's so sad how the best compilers are the free ones where the gain is honor rather than money.



I've seen one written in.. i think it was called delphie or something...



I don't know about this floormodel here. I think this one's older than me.. lol It's at least 15 years old. This is one rugged tv.



I think it has something more to do with how fast they move on the screen rather than the actual frames that are done. I'm not sure though, i've never gotten that far into graphics development cause i never found a tutorial simple enough. But by the time your comp gets slowed down to 20, your music is noticibly slower. Perhaps the need for 60 has something to with lack of ability to code your own, and decent, sycronization scheme.



true, and you can do all of that, but i hate how companies do that. Plus, if you saw my taskbar you'd understand why i'm so criticle of speed handy applications. lol Trust me, it's scary.

[quote=kohlrak]
I have a simple rule... If it is used once, it dosn't go into a function. On the flip side, people are usually told to put big sections of code into functions, even if it's only used once. So the flip side needs to learn how to use the inline, if they're going to do that, so that the code will be at least a bit faster.
[/quote]
If you're only calling it once, there's (usually) no reason to inline it, speedwise. And it's much easier to read a bunch of small functions than a single monolithic one (try looking at projects not written by yourself).

[quote=kohlrak]
Well, first off, since they depend on each other you'll want to make whatever code that the GPU must execute (such as the algorithams to decode the models or images) you'll want to make that as small as you can (because from what i've heard, the GPU runs a bit slower than the regular processor) and even a slow calculation on the AI can be pretty laggy if you have a complex enough AI, and now people are getting more and more concerned with how "smart" their "ai" are.
[/quote]
GPUs have have lower clock frequencies than CPUs, but they're extremely fast at what they do - relatively specialized functions. (Funny thing is that those operations aren't just graphics limited, and with the GF8800 and later generic programmable versions, we're going to see interesting stuff).

[quote=kohlrak]
Just enough to give the company a good outlook so the product sells. Let's not forget what some people THINK are optimizations, but really the opposit.
[/quote]
Heh. Again, check quake3 - there's some pretty nizzle stuff there, programmer pride, not just "selling the game". And as for "THINK are optimizations", remember your nit-picking about calling conventions

[quote=kohlrak]
Just looking at the quality of the popular C++ classes, i could just imagin how poor the assembly information can be, since it is hard to get, we really can't get very picky with what we ask for. I find it alot easier to optimize in assembly than C++. When i think of the best way to do the calculations, i usually miss alot.
[/quote]
You're bitching about code quality, and at the same time saying "we'll have to use what we can get" - that doesn't compute. Also, considering how much C and C++ code there's around, a lot of it sucks - but have a look at things like the MACH kernel, and code from the *BSD projects - that's generally pretty high quality code.

Dunno if it's easier to optimize in assembly, but it's certainly where you can gain the largest optimizations.

[quote=kohlrak]
Keyword bolded and underlined, and even then. How hard are they trying?
[/quote]
Hard enough that they actually produce quality

[quote=kohlrak]
Windows programmers are supposed to "program on the defencive." Whatever happened to that logic when making an API? I never made a DLL in assembly, but you better beleive that if i did i'd make sure that some sort of predictable return value was sent, weather it be an example of windows' troolean logic to tell if there were any problems or not. There's no excuse not to do this. Personally, i think that coders making things should also be a little more considerate about conservation of the registers. For instance, if you don't have a creative use for what you put in the registers other than eax, perhaps you should consider putting a warning, at least, that those registers are going to be edited.
[/quote]
Not all of the Windows API is well designed - especially not things like the "common controls" introduced with IE. But return values are necessary... unless you want to introduce something like 'errno'.

Registers, ho humm. The existing calling conventions makes a lot of sense, actually - scratch and persistance. If it wasn't done this way, either functions would be free to trash all registers (and caller would have to preserve everything, often a waste of time), functions would have to preserve all registers (not really needed, again a waste of time), or you'd have per-function specification (a horrible mess).

Also do keep in mind that any wide-spread OS is written "for the masses", so it's written in C...

[quote=kohlrak]
Yet, in my C++ class, we're not allowed to use things that we havn't covered yet, that includes things we'll never cover.
[/quote]
It makes sense having to cover the basics before you move on, and be limited to the basics so you learn them well - not everybody knows a lot when they take a computer class. Sucks if there's important topics you won't cover, and from other posts you've written it sounds like your class sucks. Things aren't like that everywhere though. I can only speak from what I know from Denmark, where the quality is generally very high.

[quote=kohlrak]
Now, i could easily use alot of the binary operators to enhance the execution time very, very greatly.
[/quote]
Where would you use this to enhance execution time so much? It sounds like you're doing a lot of useless micro-optimizations that you don't get much benefit from, instead of writing clear code and doing optimizations where they matter.

[quote=rugxulo]
I heard once that the human eye can't even detect FPS above a certain number (20??) ... besides, I think 60 FPS is unreasonable, many games are playable with only half that (or less!)
[/quote]
The cited fps rate is 24 - but I've never seen a reliable source. And there's certainly a difference in smoothness in games from 24 to 65fps, but that is also related to animation smoothness etc. But then there's 60 vs 85 (or higher) refresh rates for CRT monitors - that's very noticable too... so I think the 24fps figure is wrong.

Nothing sad about that. Good is good, free or otherwise. Besides, if the best is free, woohoo! Can't complain.

(BTW, what C++ compiler is the best? I assume GCC, but some would probably say MSVC.)


I think C being free form makes it much MUCH easier to write ugly code. IOCCC was actually inspired by a sh clone or whatever. Plus, there are just too many C/C++ compilers (although I actually like that ... fun!) and standards (ANSI, DOS, Win, *nix, C99, POSIX, K&R, etc.). That's just my opinion, though. (Maybe if I didn't suck at C, but it's just such a seemingly HUGE language with a billion quirks ... argh).


OS/2 had a kernel written in assembly (supposedly), and that was popular. Face it, writing portable HLL (e.g., C) code is cool and all, but it isn't always the best idea. Your replies always seem a bit biased (in a good way, I guess) based on your experience. Your opinion is always valuable to me, though.


They don't force you guys to learn C++ just because BS is from there, do they?

"Depends"

For x86, MSVC (2003 or newer, '98 is really outdated and 2001 has bugs) and Intel's compilers are very good. GCC 3.x usually lags behind, and I haven't bothered to play with GCC4 yet (supposedly finally introduced some optimizations VC has had for years which help a lot), but there isn't an official mingw port of it yet, and I've heard that some linux apps break with V4 - although that's probably more a fault of the app than GCC


You can write REALLY ugly code in C/C++, and some do this. Shame on them. On the other hand it's also possible to write pretty clean, lean and nice code. Just like it's possible to write commented and fairly readable assembly


If you stick to ANSI, you can get your code working most places. I hope I'll never have to write for pre-ANSI platforms, as that's IMHO broken. I prefer ISO C++, but ANSI C will do. Lots of your core stuff can be written in clean and portable ANSI or ISO, and then the OS-specific interfacing done with POSIX, WIN32, whatever.

No, you don't get much done from 100% portable code (at least without some portable framework ), but the OS glue doesn't necessarily have to be too thick (you could write, say, a portable torrent client with a portable core, and OS glue for NT IOCP, linux /dev/epoll, BSD /dev/kqueue - if you need an UI, that'd take some more ). And if you don't mind frameworks, well, there's a lot of them around for various stuff.


I somehow doubt it was assembly - although, given the period it was written in, it could have sizable assembly parts. Haven't ever played with OS/2 though, so couldn't tell . But, around here, it was only die-hard fans that used OS/2, after MS backstabbed IBM and did NT.


Indeed.

Especially things like the critical parts of real-time OSes.


I'd be a hypocritical liar if I claimed I wasn't biased

Funny thing is I can recognize "the younger me" in a lot of current die-hard assembly users. Heck, I think there's even a document I wrote as late as ~2000 that says something similar to "WRITE MOST OF OS KERNEL IN ASM!!!". Since then I've gained more experience and compilers have become better...

Computers have become faster as well, but I still keep old hardware around for testing... I usually don't need to resort to assembly to get decent speed, though - the trick is to write non-retarded code, and think about data structures and algorithms (and be lazy and use STL or whatever when it doesn't matter ^_^).

But then again do keep in mind that I don't really do sound or graphics programming. If I did, I'd probably do assembly more than I do those days. If for nothing else, because it's fun



*grin*

Nah, more like because it's probably the most widespread language that has plenty of grunt. I think most of the comp.sci. courses start with JAVA though, but then progress through a wide range of language of various classes. The comp.eng. course I'm going to attend next year focuses more on C++ and pure C, JAVA isn't good for all embedded devices. It's okay on phones, but I wouldn't like the idea of it on anything critical - not even with one of those "JAVA CPUs".

Friend experienced in area told me that java for mobile phones is completely unportable. There is no standard interface for accessing those devices.

Wouldn't surprise me - you can probably do some fairly trivial stuff portably, though (the j2ee or whatever subset) - and it shouldn't be too hard targetting multiple devices.

But sorta sucks having to recompile when the idea of java is "bytecode that runs everywhere" . Heck, some games written for a K500i won't even run on a K750i - how sucky is that?

Here's a practically full-speed GPL Sinclair Zx Spectrum 48k emulator for the Sony Ericsson P900 phone written almost entirely in C++ using Linux. (Haven't tried it, don't have a P900, but just FYI).

Maverick, we will do rom dumps of our brain and run ourselves emulated on the fasted multi-core light processors ever designed.