flat assembler
Message board for the users of flat assembler.

flat assembler > Heap > The Compiler Returns! (Vs The mummy returns)

Goto page Previous  1, 2, 3  Next
Author
Thread Post new topic Reply to topic
DustWolf



Joined: 26 Jan 2006
Posts: 373
Location: Ljubljana, Slovenia
rugxulo wrote:
Am I the only one who balks every time C is called "low level"?? It's nowhere near as low level as assembly. There are things you just can't do in C (standard, especially).


C is not low level. Not in the view of what you can do with it and not in the view of how it works either. Being HLL is C's whole point.

However people nowadays find it benerficiary to spread dissinformation and there are a lot of people who claim to understand something, but don't. To them C is low level. Because programming in C does things that actually have something to do with the hardware below (pointers, etc).

I hate stupid Java people.
Post 08 Jun 2007, 10:43
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
And then to top it off, C and C++ get over credited. Sometimes they say that C is overkill. I'm not kidding you. Am i the only one who thinks that that thought is pathetic?

EDIT: and i'm taking java next year. Interestingly, it's considered an A.P. course (the only computer A.P. couse) meaning if i pass they'll pay part of my way to collage. So, what's going on is they are practically bribing us to take java over all the other programming courses. There's only 1 good thing about java, and that's web apps for when you're too lazy to learn how to program on other platforms. Even the "java theory" was shot down, meaning that it's cross platform ability isn't what it's cracked up to be.
Post 11 Jun 2007, 18:51
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)
I have to ask: does anyone these days even care about "backwards compatibility" or "portability"? Seems not. If all you "port" to is Win32 and x86 Linux, it's hardly portable. And if your minimum requirements are 256 MB RAM, you ain't too backwards compatible. Very few programs written in C are actually as portable as C brags about being, especially these days. And Java isn't exactly lightweight. And Python and Perl? I dunno, too overhyped. Why is everything about "market share"? (ugh)
Post 13 Jun 2007, 00:25
View user's profile Send private message Visit poster's website Reply with quote
f0dder



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

But here's the problem. I've run into so many errors in my C++ code that were only fixable with "patches." For example, i called cin >> (), got my junk, but then i wanted to call cin.getline(), which i had to do twice, because i had to patch it for the first one. I find this irresponsible way of getting your code to work, and things like this were my main reson for going to assembly.

That just shows you don't understand C++ well enough, go RAFB before you blame your own incompetence on the language and the stdlib.

DustWolf wrote:

Try debugging in C and in ASM and tell me if not being able to read your own code in a debugger direcly is a great plus and if errors in C code are any more obvious than the ones in ASM (not to mention most of the errors one can easily make in C, would only appear in ASM code after 3 days of no sleep and no coffee).

You don't debug highlevel code in a asm-only debugger, that's plain stupidity. You use a decent high-level debugger that can handle complex break expressions, has data-type viewers, et cetera. It's about automating trivial repetitive tasks and debugging smarter instead of harder. And don't give me some bullshit about not being able to trace in assembly, I've spent countless hours with softice.

rugxulo: python and perl are overhyped indeed, and portability with python is pretty damn ugly. Both are very fine tools though, to be applied where they make sense.

As for the portability of C/C++, it all comes down to how you design your code. If you separate program logic and interface code, and code at the right level of abstraction, you can get very portable code. Yes, you'll need to rewrite some stuff per-platform if you don't use some whatever portable library that handles everything you need, but for real-world projects the amount of code that needs to be rewritten per platform will be miniscule compared to the full project size.

kohlrak: worrying about executable size to the extent you do is pretty pointless. If you use the CRT, you're not taking an unnecessary size hit, and if you're not using it, you simply don't include it. Judging anything by "hello, world" disclassifies your opinions from being valid. What you want to look at is how much a program grows once you start adding code.

And of course anybody with some sense in their heads has the default optimizations set to optimize for size, with the hot-spots set for speed. And of course hot-spots are identified by profiling, and if things aren't good enough after data-structure and algorithm+implementation enhancements, assembly is considered.

shash^clp is right in a lot of what he says. Go take a look at what [url=farbraushc]http://www.farb-rausch.net[/url] are capable of doing... yeah, it's exe-compressed, but it's C++. Go take a look at www.pouet.net 64kb and 4kb intros. Those are people who actually know their tools and languages, and aren't talking shit based on lack of knowledge.
Post 13 Jun 2007, 11:52
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
Quote:
That just shows you don't understand C++ well enough, go RAFB before you blame your own incompetence on the language and the stdlib.


I have yet to find anywhere where i can get decent info on stdlib. I have learned all i know about it from experience. Try looking in the header files of most compilers and you get an unreadable mess. The crap is ugly. And i know C++ pretty damn well. I've used it for over 2 years. I don't need you tryin' to tell me i don't know something i have more than enough experience in. I've had enough of it to hate it. It's like the government. You get shit from it but the whole thing is intended to be shrouded in mist.

Quote:
You don't debug highlevel code in a asm-only debugger, that's plain stupidity.


Which is his point. It's so ugly and messed up that it is stupid to use an assembly debugger. It shouldn't be that ugly.

Quote:
As for the portability of C/C++, it all comes down to how you design your code.


That's good. You forget, though, that a factor of a language is how it is used, not just the language itself. For instance, if alot of people don't know what goes on in a programmg language, then that is a fault with the programming language as well. You need to take EVERYTHING into account.

Quote:
Yes, you'll need to rewrite some stuff per-platform if you don't use some whatever portable library that handles everything you need, but for real-world projects the amount of code that needs to be rewritten per platform will be miniscule compared to the full project size.


Not perfectly portible, now is it? It's advertised to be perfectly portible.

Quote:
worrying about executable size to the extent you do is pretty pointless. If you use the CRT, you're not taking an unnecessary size hit, and if you're not using it, you simply don't include it. Judging anything by "hello, world" disclassifies your opinions from being valid. What you want to look at is how much a program grows once you start adding code.


It grows multiplicitively (sp?). In other words, the results get alot worse as you go. And it's not pointless. It may be hard for you to believe, but alot of the people i make my target applications for are either people who want them so small they fit on a floppy with other programs or people who just need simple programs while they're on a dialup connection. I develop out of hobby, not buisness. Therefor, i would prefer 2kb over 200kb. Plus, i'm leaving the STDLIB behind me anyway. It's not my bag of chips.

Quote:
And of course anybody with some sense in their heads has the default optimizations set to optimize for size, with the hot-spots set for speed. And of course hot-spots are identified by profiling, and if things aren't good enough after data-structure and algorithm+implementation enhancements, assembly is considered.


I rest my case... Though not everyone with sence in their heads. Because alot of people end up with programs where everything is hidden, and they dont' train us on how to use the damn compilers. We have to guess. And most of us are too lazy to sit there and find out what all our compiler does because most of it is BS that we'll never use. Some of it uses API specific terms we don't know so we ignor it or get disarrayed.

Quote:
Those are people who actually know their tools and languages, and aren't talking shit based on lack of knowledge.


*YOU* wanna talk about a lack of knowledge...? You gotta be one motivated son of a bitch to learn the ins and outs of HLLs. Trust me, most people don't have the patients. The users really do make a good cut of how you judge the language. It's like making an awesome tool that will do alot of stuff for you. It'll optimise your code, and other features. But no help command and it's command line and only documentation on how to enter commands. That's what HLLs are like these days. You'd have to go out and look for tutorials on using each feature of the program, and some of those tutorials might be a bunch of BS by some one who used an older version. And you'll never find every feature. That's like HLLs. Sounds like a shit load of fun, dosn't it?
Post 13 Jun 2007, 14:33
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
kohlrak wrote:

I have yet to find anywhere where i can get decent info on stdlib. I have learned all i know about it from experience. Try looking in the header files of most compilers and you get an unreadable mess. The crap is ugly. And i know C++ pretty damn well. I've used it for over 2 years. I don't need you tryin' to tell me i don't know something i have more than enough experience in. I've had enough of it to hate it. It's like the government. You get shit from it but the whole thing is intended to be shrouded in mist.

Again, RAFB. You keep saying you're experienced in C/C++, but your statements show otherwise.

kohlrak wrote:

Which is his point. It's so ugly and messed up that it is stupid to use an assembly debugger. It shouldn't be that ugly.

Would you use a toothbrush to clean your entire house? And when is the last time you've tried debugging heavily hand-optimized assembly code without comments? Anyway, compiler code isn't that ugly once you learn the patterns, it's just pointless not using the right tool for the job. Don't waste your time doing things the tedious way when they can be done smarter, faster, easier.

kohlrak wrote:

That's good. You forget, though, that a factor of a language is how it is used, not just the language itself. For instance, if alot of people don't know what goes on in a programmg language, then that is a fault with the programming language as well. You need to take EVERYTHING into account.

So you're going to judge a language because some people don't use it properly? I guess assembly should be condemned to hell, then Wink

kohlrak wrote:

Not perfectly portible, now is it? It's advertised to be perfectly portible.

I've never claimed it's "perfectly portable", but properly written C/C++ is among the most portable code, while still delivering decent performance. Not even java is 100% portable, and it doesn't offer nowhere near the performance of C/C++.

kohlrak wrote:

It grows multiplicitively (sp?). In other words, the results get alot worse as you go.

You mean it has non-linear growth, which is some pretty old false FUD. And if your own programs do grow in this way, well, you must be writing pretty shit code, or be using a pretty shitty compiler, or both Smile

kohlrak wrote:

And it's not pointless. It may be hard for you to believe, but alot of the people i make my target applications for are either people who want them so small they fit on a floppy with other programs or people who just need simple programs while they're on a dialup connection.

So I guess 100kb for a fully-fledged application is way too much? The overhead of crt isn't too bad, when you're doing real-world applications that actually use that code. And again, it's easy getting rid of the CRT if you need to write small apps. Or use a replacement CRT like Jørgen "Jibz" Ibsen's WCRT.

kohlrak wrote:

You gotta be one motivated son of a bitch to learn the ins and outs of HLLs. Trust me, most people don't have the patients.

You don't really need that much knowledge to write decent code. Writing good code takes experience, though, no matter which language you choose. And good design principles are, largely, independent of the language you choose (though each language has it's own dogmas).

It takes quite a lot if you want to write decent assembly, too... if you're going to write mediocre shit, you might as well not do assembly since a compiler will beat you anyway (that's for people who argue that assembly will always be fastest and smallest - if your reason for using assembly is because you like it, fine by me).

kohlrak wrote:

But no help command and it's command line and only documentation on how to enter commands. That's what HLLs are like these days. You'd have to go out and look for tutorials on using each feature of the program, and some of those tutorials might be a bunch of BS by some one who used an older version. And you'll never find every feature. That's like HLLs. Sounds like a shit load of fun, dosn't it?

Sounds like you have GUIs and Wizards confused with languages.
Post 13 Jun 2007, 15:04
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
Quote:
Again, RAFB. You keep saying you're experienced in C/C++, but your statements show otherwise.


The books stores in my area suck. And it just so happens i've already decided to go to a nearby mall to find the bookstore there incase i can find something decent there, but i 'm not getting my hopes up. So, unless you can provide a book store in my own state with some decent books, or if you plan on buying a shitload of books for me, i suggest you change your suggestions. Especially if you don't want to go through the trouble of contacting a bunch of people in my area to organize some time for me to read the damn book. And since i don't have all their numbers, you'll have to do some digging on your own.

Quote:
Would you use a toothbrush to clean your entire house? And when is the last time you've tried debugging heavily hand-optimized assembly code without comments? Anyway, compiler code isn't that ugly once you learn the patterns, it's just pointless not using the right tool for the job. Don't waste your time doing things the tedious way when they can be done smarter, faster, easier.


Are you daring to say infront of all these people that you believe machines made by humans are better than humans?

Quote:
So you're going to judge a language because some people don't use it properly? I guess assembly should be condemned to hell, then


Some? You havn't seen the bullshit i've seen. The few ASM programs i've seen built are built alot better than anything i've seen in C++. I've seen alot of memo leaks result.

Quote:
I've never claimed it's "perfectly portable", but properly written C/C++ is among the most portable code, while still delivering decent performance. Not even java is 100% portable, and it doesn't offer nowhere near the performance of C/C++.


I'm aware. Thing is, they're advertised as portable, and that you should use them instead of ASM because they're "portable."

Quote:
You mean it has non-linear growth, which is some pretty old false FUD. And if your own programs do grow in this way, well, you must be writing pretty shit code, or be using a pretty shitty compiler, or both


All compilers are pretty shitty.

Quote:
So I guess 100kb for a fully-fledged application is way too much? The overhead of crt isn't too bad, when you're doing real-world applications that actually use that code. And again, it's easy getting rid of the CRT if you need to write small apps. Or use a replacement CRT like Jørgen "Jibz" Ibsen's WCRT.


Or do it yourself, then you actually understand it.

Quote:
You don't really need that much knowledge to write decent code. Writing good code takes experience, though, no matter which language you choose. And good design principles are, largely, independent of the language you choose (though each language has it's own dogmas).


Decent code is easy. Understanding the compiler to the degree you expect me to isn't.

Quote:
It takes quite a lot if you want to write decent assembly, too... if you're going to write mediocre shit, you might as well not do assembly since a compiler will beat you anyway (that's for people who argue that assembly will always be fastest and smallest - if your reason for using assembly is because you like it, fine by me).


The best ASM algorithem can only be equal or better to the best C/C++ algorithem. Humans made the compiler, therefor it can't be better than the human for things are as only strong as their weakest link. The best that the compiler can hope for is some one dumber than the one who made it or to tie the one who made it. Simple logic.

Quote:
Sounds like you have GUIs and Wizards confused with languages.


Much broder than that. HLLs have alot of shit in them but we don't know how to use it. The tuts for them are mostly shit, and there's little you can hope for in the line of actually knowing what goes on. Takes a bit of reading, which many of us would rather be making programs than sitting there reading a book on BS that shouldn't be as complicated as it is. I'm not about to let a poorly documented compiler for a poorly documented programming language to decide what is best for me and my desires.
Post 13 Jun 2007, 15:24
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
Books: www.amazon.com - that's what the rest of us use (though use the .co.uk version). I can give you some recommendations if you care. But don't expect to be good at programming from some so-so tutorials from the net written by people who don't master the language.

kohlrak wrote:

Are you daring to say infront of all these people that you believe machines made by humans are better than humans?

I dare say that you need to put a little effort into your manual coding in order to beat a decent compiler, yes. More effort than it requires writing the code in a HLL. Nobody worth listening to is going to argue that you can't beat a compiler, that's not what I'm saying.

kohlrak wrote:

Some? You havn't seen the bullshit i've seen. The few ASM programs i've seen built are built alot better than anything i've seen in C++. I've seen alot of memo leaks result.

So, C/C++ is a bad language because you've seen shit code? Hurray. Well, you should see the assembly code I've sifted through over the years. Whose big is dickest?

kohlrak wrote:

I'm aware. Thing is, they're advertised as portable, and that you should use them instead of ASM because they're "portable."

And obviously C/C++ is a lot more portable than assembly. The best you can really do is different OS'es on the same architecture - try porting an x86 assembly program to ARM or Itanium. Of course you could do a lowest-common-denominator meta-assembler, but then you'd be better off with C/C++ anyway.

kohlrak wrote:

All compilers are pretty shitty.

That's quite a blatant claim to make. Perhaps it's your code writing skills that suck Smile

kohlrak wrote:

Or do it yourself, then you actually understand it.

D:\src\lib\wlibc ... complete enough to write functional programs, but I abandoned the project when I found jibz' WCRT, no need to duplicate efforts. In the past I contributed to a 32bit dos-extended libc implementation.

kohlrak wrote:

Decent code is easy. Understanding the compiler to the degree you expect me to isn't.

You don't need much compiler knowledge to write decent code. You do need some architecture knowledge (yep, assembly is useful), and you do need algorithmic knowledge.

kohlrak wrote:

The best ASM algorithem can only be equal or better to the best C/C++ algorithem. Humans made the compiler, therefor it can't be better than the human for things are as only strong as their weakest link.

Stating the obvious?

kohlrak wrote:

The best that the compiler can hope for is some one dumber than the one who made it or to tie the one who made it. Simple logic.

I think you're missing the point. The point is that the compiler takes care of all the trivial things that you don't really want to be bothered with, when you want to complete a real-world project in a lifetime. Obviously you can always beat a compiler (except in those very few cases where the compiler produces optimal code), but ask yourself - are you going to scrutinize every single line of code in a big project?

I'm not. Instead I let a compiler produce decent-enough code for the majority of my project, and hand-tune where it's necessary (or "profitable" - I've often optimized bits of code that didn't require optimizing, but where it was either fun to do, or allowed me to run the app at much lower-specced machines than I was targetting).

kohlrak wrote:

Much broder than that. HLLs have alot of shit in them but we don't know how to use it. The tuts for them are mostly shit, and there's little you can hope for in the line of actually knowing what goes on.

"tuts" written by inexperienced people, as opposed to compiler documentation and proper books on the language... well, what would you expect?

You don't need to use every frigging feature of a language to use it effectively, just how often do you use SMSW or LGDT in your assembly projects? The great thing of C++ is that it's multi-paradigm, you can do procedural, object-oriented or even template metaprogramming functional-like magic. you choose.

kohlrak wrote:

Takes a bit of reading, which many of us would rather be making programs than sitting there reading a book on BS that shouldn't be as complicated as it is.

So, you claim you can write decent assembly code without some studying beforehand?

kohlrak wrote:

I'm not about to let a poorly documented compiler for a poorly documented programming language to decide what is best for me and my desires.

Heh, poorly documented?

Microsoft MSVC has pretty damn good documentation, and there's a lot of decent documentation on GNU GCC as well (even though it's imho not as neatly indexed). If you're too stupid to find & understand it, perhaps you shouldn't be programming in the first place.

There's also a lot of good texts on C/C++ as well, which isn't very weird considering how old those two languages are. Yes, you'll have to pay for some of it, but everybody's got to make a living. If you don't want to do that, fine, but don't make bogus claims about things you clearly don't have enough experience with.
Post 13 Jun 2007, 23:19
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
Quote:
Books: www.amazon.com - that's what the rest of us use (though use the .co.uk version). I can give you some recommendations if you care. But don't expect to be good at programming from some so-so tutorials from the net written by people who don't master the language.


That's the where, now about about the money the time and the convincing of my father who distributes the money that it's not going to rip him off?

Quote:
I dare say that you need to put a little effort into your manual coding in order to beat a decent compiler, yes. More effort than it requires writing the code in a HLL. Nobody worth listening to is going to argue that you can't beat a compiler, that's not what I'm saying.


Sure as hell sounds like that's what you're trying to say.

Quote:
So, C/C++ is a bad language because you've seen shit code? Hurray. Well, you should see the assembly code I've sifted through over the years. Whose big is dickest?


I havn't seen much errored assembly code, with the exception of the help requests. On the other hand, i can google C++ code that won't even compile. I still remember my quest for a decent Win32 API tutorial in C++. I never did find one. On the contrary, i did in assembly.

Quote:
And obviously C/C++ is a lot more portable than assembly. The best you can really do is different OS'es on the same architecture - try porting an x86 assembly program to ARM or Itanium. Of course you could do a lowest-common-denominator meta-assembler, but then you'd be better off with C/C++ anyway.


But they're still not what they advertise. That's the point of this argument. The glove dosn't fit. Their claims don't match the reality.

Quote:
That's quite a blatant claim to make. Perhaps it's your code writing skills that suck


Or maybe it's the compiler.

Quote:
D:\src\lib\wlibc ... complete enough to write functional programs, but I abandoned the project when I found jibz' WCRT, no need to duplicate efforts. In the past I contributed to a 32bit dos-extended libc implementation.


I seldom trust anyone else's junk. I have to trust microsoft and the headers with fasm are straight forward enough to make me happy. But that's beside the concept that using some one else's code is your funeral. It's why i avoid CRT when i can.

Quote:
You don't need much compiler knowledge to write decent code. You do need some architecture knowledge (yep, assembly is useful), and you do need algorithmic knowledge.


The algorithem is what makes or breaks your code. The compiler, though, can worsen your algorithem.

Quote:
Stating the obvious?


I have a tendency of doing that. Especially when i feel the obvious has eluded some.

Quote:
I think you're missing the point. The point is that the compiler takes care of all the trivial things that you don't really want to be bothered with, when you want to complete a real-world project in a lifetime. Obviously you can always beat a compiler (except in those very few cases where the compiler produces optimal code), but ask yourself - are you going to scrutinize every single line of code in a big project?


I've noticed that bottle necks need optimized code, and every line would make a big difference in a bottle neck. Compiler wouldn't be so bad if it used assembly optimization, but once a human optimizes it, it's no longer just compiler code and would invalidate the argument for the case of the compiler. I would rather type up a bunch of boring junk than sit there and not have enough speed in an important section. And for those who don't like it, there's always macro which you write and only what you write will go into it. Don't like messing with fpu instructions (for example)?

Code:
;assumes it's executed in a writeable section

chfaddvar dq 0

macro mhfadd alpha, beta { ;Alpha and beta must be pointers
      lds [hfaddone]
      lds [hfaddtwo]
      faddp
       fstp [alpha] }

macro chfadd alpha, beta { ;Alpha must be a pointer.
        mov [chfaddvar], beta
       lds [hfaddone]
      lds [hfaddtwo]
      faddp
       fstp [alpha] }     


Too lazy to test them out and my head hurts so i'm not garenteein' that'll work but it's for example purposes. Anyway, the fun part about that is people would have to understand them to use them too. Then people know what's going on.

Quote:
I'm not. Instead I let a compiler produce decent-enough code for the majority of my project, and hand-tune where it's necessary (or "profitable" - I've often optimized bits of code that didn't require optimizing, but where it was either fun to do, or allowed me to run the app at much lower-specced machines than I was targetting).


Requires ASM, dosn't it? Most who vouch entirely for HLLs don't know any ASM.

Quote:
"tuts" written by inexperienced people, as opposed to compiler documentation and proper books on the language... well, what would you expect?


Books aren't always available to some people. I've noticed that alot of your HLL lovers happen to be people with nothing but the internet. Those tuts are a reflection of the users of the language.

Quote:
You don't need to use every frigging feature of a language to use it effectively, just how often do you use SMSW or LGDT in your assembly projects? The great thing of C++ is that it's multi-paradigm, you can do procedural, object-oriented or even template metaprogramming functional-like magic. you choose.


Some choice...

Quote:
So, you claim you can write decent assembly code without some studying beforehand?


No. But i am saying that understanding the compiler does take a bit more reading than assembly. Alot with assembly has to be learned from experience, which is contrary to the compiler. With the compiler, the only experience which you get from using it is how to make your programs compile and how to make it bug free. Not much on the actual usage of the compiler. i still don't understand DEV-C++ or MSVS.

Quote:
even though it's imho not as neatly indexed


Makes a big difference.

Quote:
If you're too stupid to find & understand it, perhaps you shouldn't be programming in the first place.


Reminds me of the directx documentation. That was ugly... I've seen alot of "loops" in the documentation where they tell you to go here for more information, then go here for more information, and then another here for more information, and they never do give you more information, instead they just give you a handfull of pages that set up a web of "Go to here for more information." Eventually, i gave up on the documentation.

Quote:
There's also a lot of good texts on C/C++ as well, which isn't very weird considering how old those two languages are. Yes, you'll have to pay for some of it, but everybody's got to make a living. If you don't want to do that, fine, but don't make bogus claims about things you clearly don't have enough experience with.


Not everyone has control of their money if you havn't noticed it. I'd be more than happy to spend money on books for the topcs i'm into, but my father won't allow it. I'm sure i'm not the only one who has to make do with what they have (and i'm not talking about just this forum, i mean everywhere out there). And how much experience do you have with C and C++ again?
Post 14 Jun 2007, 00:22
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
Kohlrak wrote:

That's the where, now about about the money the time and the convincing of my father who distributes the money that it's not going to rip him off?

Find a spare-time job like the rest of us did around your age? Smile

Kohlrak wrote:

f0dder wrote:

Nobody worth listening to is going to argue that you can't beat a compiler, that's not what I'm saying.

Sure as hell sounds like that's what you're trying to say.

Then you're reading what you want to read.

Kohlrak wrote:

I havn't seen much errored assembly code, with the exception of the help requests. On the other hand, i can google C++ code that won't even compile.

Errored is one thing, piss-poor is another. C++ code that won't compile? Either you need to find other sources, or you need to ditch VC6 and find a recent compiler.

Kohlrak wrote:

I still remember my quest for a decent Win32 API tutorial in C++. I never did find one. On the contrary, i did in assembly.

Iczelion's tutorials were based on Charles Petzold's "Programming Windows", and pretty closely based at that. Microsoft's MSDN/PlatformSDK isn't half bad either, although it's a reference and not a tutorial. And there's sites like codeproject that's pretty decent as well.

Kohlrak wrote:

But they're still not what they advertise. That's the point of this argument. The glove dosn't fit. Their claims don't match the reality.

Still not what who advertise? A professional that's used a lot of languages, or some zealot on irc/usenet/whatever? I doubt you'll find a more portable language than C/C++ anyway, simply because it's so old and rugged.

Kohlrak wrote:

f0dder wrote:

That's quite a blatant claim to make. Perhaps it's your code writing skills that suck

Or maybe it's the compiler.

I wouldn't put my bets on it Wink

Kohlrak wrote:

I seldom trust anyone else's junk. I have to trust microsoft and the headers with fasm are straight forward enough to make me happy. But that's beside the concept that using some one else's code is your funeral. It's why i avoid CRT when i can.

The benefit of using CRT is that it's undergone a lot of scrutiny. It might not be _the best_ implementation of everything, but it's going to be decent enough for most tasks, relatively bug-free, etc. The STL is usually of pretty decent quality too. It's stupid reinventing the wheel when there isn't a need to do it.

The STL is good enough to handle, sort, etc. tens of thousands of records on a 200mhz machine with 64megs of ram, without even taxing the hardware, and that's with only a few lines of code. If I need better performance than that, I can always hand-code, and if that's not good enough, I can resort to assembly.

Kohlrak wrote:

The algorithem is what makes or breaks your code. The compiler, though, can worsen your algorithem.

Algorithm and the data structures you choose, yes. And of course the implementation of the algorithm matters. Considering the assembly code I see a lot of people write, I unfortunately have more faith in compilers than people like you. Not because compilers do a super-fantastic job, but a lot of people think too highly of themselves.

Kohlrak wrote:

I've noticed that bottle necks need optimized code, and every line would make a big difference in a bottle neck.

Duh. How many percent of your application has bottlenecks, though?

Kohlrak wrote:

Compiler wouldn't be so bad if it used assembly optimization, but once a human optimizes it, it's no longer just compiler code and would invalidate the argument for the case of the compiler.

Compilers use heuristics, which tend to work quite well for the majority of your code. For the rest, identified by profiling, you do a little hand-holding or write the stuff manually in assembly. But we're talking a _very_ few percent of critical code, here.

Kohlrak wrote:

I would rather type up a bunch of boring junk than sit there and not have enough speed in an important section. And for those who don't like it, there's always macro which you write and only what you write will go into it.

"Not enough performance" falls into the category of those few percent of the code that matters enough to pay special attention to it. Problem with your macros is that they have fixed register allocation and don't have any previous knowledge of what's on the FPU stack, etc. - a compiler should easily beat trivial cases like that. What you want to do, when optimizing, is take a full algorithm and optimize it properly.


Kohlrak wrote:

f0dder wrote:

I'm not. Instead I let a compiler produce decent-enough code for the majority of my project, and hand-tune where it's necessary (or "profitable" - I've often optimized bits of code that didn't require optimizing, but where it was either fun to do, or allowed me to run the app at much lower-specced machines than I was targetting).

Requires ASM, dosn't it? Most who vouch entirely for HLLs don't know any ASM.

Depends on the kind of code you write. You can do a lot of optimization without a single line of assembly... check some of the strlen algorithms, for instance. Or tricks like representing a huffman tree as an array instead of pointer-based tree. But sure thing, assembly knowledge isn't a bad thing, and I'm not one of the persons that claim assembly is 100% dead.

Kohlrak wrote:

f0dder wrote:

So, you claim you can write decent assembly code without some studying beforehand?

No. But i am saying that understanding the compiler does take a bit more reading than assembly. Alot with assembly has to be learned from experience, which is contrary to the compiler. With the compiler, the only experience which you get from using it is how to make your programs compile and how to make it bug free. Not much on the actual usage of the compiler. i still don't understand DEV-C++ or MSVS.

Ummm... There's language and there's compiler. Compiling something is as simple as "cl myfile.c" or "g++ myfile.cc", depending on your compiler of choice, whether you're doing C/C++, etc. If you want more fancy things, you add some switches, which are pretty well documented. If you feel you have a need for more advanced optimizations switches, you dig into the documentation. Simple as that, when you're writing standard code.

What is there to "understand" from GCC or MSVC? (not dev-cpp or MSVS, which are IDEs, not compilers).

Kohlrak wrote:

Reminds me of the directx documentation. That was ugly... I've seen alot of "loops" in the documentation where they tell you to go here for more information, then go here for more information, and then another here for more information, and they never do give you more information, instead they just give you a handfull of pages that set up a web of "Go to here for more information." Eventually, i gave up on the documentation.

Funny, I found the DirectX documentation pretty fulfilling for my needs - perhaps I was reading different versions than you (DX5,7,Cool. Must admit I haven't done terribly advanced DX things, and mostly stuck with 2D stuff. And I will certainly admit it's a mouthful to digest, especially if you've never done accelerated graphics programming before. I coded plain int13 stuff, allegro and some OpenGL stuff before moving to DirectX, so I guess I was at an advantage, and didn't find it too awful. It's a bit more comfortable in C++ than C, though.

Kohlrak wrote:

Not everyone has control of their money if you havn't noticed it. I'd be more than happy to spend money on books for the topcs i'm into, but my father won't allow it.

That's too bad. Please accept, then, that you do not have the proper insight to judge C/C++. Yes, I will happily agree that it sucks having to shell out bucks to get a decent understanding of the language (shelling out bucks for a compiler is bad enough - the free GCC is decent enough for more than getting you started, though).

Keep in mind that C/C++ isn't just a toy, it's a professional language used for heavy-duty work. Heck, I'd even argue that you should stay away from it if you're just a hobbyist writing minor projects, since there's easier and faster ways to Get Things Done (TM), and it requires experience to write good code in it (though that does apply to all languages).

Kohlrak wrote:

I'm sure i'm not the only one who has to make do with what they have (and i'm not talking about just this forum, i mean everywhere out there).

I'm not exactly a millionare myself, but I manage to pay my bills and still buy a few things here and there. Information wants to be free etc., but I don't think it's a crime awarding people for tearing out a year of their lives and writing up good material.

Kohlrak wrote:

And how much experience do you have with C and C++ again?

Around 10+ years. Enough to know that most C++ code written pre-2000 is junk, that not all C code written pre-2000 is good, and that just about all 16-bit assembly code and a lot of early 32-bit code is embarassing.

Don't take what I write too harshly, but you remind me of a younger and more ignorant me. The kind of person that's the reason a lot of high-level language coders think assembly coders are nuts, and the reason some of us don't mention assembly coding skills unless it's a requirement.
Post 14 Jun 2007, 01:37
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
Quote:
Find a spare-time job like the rest of us did around your age?


Getting the money's easy. Spending it is the problem.

Quote:
Then you're reading what you want to read.


I don't want to think you're an idiot who believes computers are superior to their creators.

Quote:
Errored is one thing, piss-poor is another. C++ code that won't compile? Either you need to find other sources, or you need to ditch VC6 and find a recent compiler.


These tutorials were pre-VC7... That's the sad part. Luckily i lost those tutorials...

Quote:
Iczelion's tutorials were based on Charles Petzold's "Programming Windows", and pretty closely based at that. Microsoft's MSDN/PlatformSDK isn't half bad either, although it's a reference and not a tutorial. And there's sites like codeproject that's pretty decent as well.


A little late for my research into that topic, irregardlessly, i didn't find those sites when i was doing my search. I ended up comming here, learning asm, and finding icz's stuff.

Quote:
Still not what who advertise? A professional that's used a lot of languages, or some zealot on irc/usenet/whatever?


How about professionals that have only used those languages? How about teachers/professors?

Quote:
I doubt you'll find a more portable language than C/C++ anyway, simply because it's so old and rugged.


Aside from java, that's true. It's much faster than java, though. If some one wanted to learn an HLL over ASM (i'd still suggest ASM first so if you must use an HLL you can at least work on the bottle neck in it) i would suggest C/C++.

Quote:
I wouldn't put my bets on it


I would.

Quote:
The benefit of using CRT is that it's undergone a lot of scrutiny. It might not be _the best_ implementation of everything, but it's going to be decent enough for most tasks, relatively bug-free, etc. The STL is usually of pretty decent quality too. It's stupid reinventing the wheel when there isn't a need to do it.


The problem is that using those imperfect implimentation too much results in dependency. In the case of need for something faster, your dependency hurts you.

Quote:
The STL is good enough to handle, sort, etc. tens of thousands of records on a 200mhz machine with 64megs of ram, without even taxing the hardware, and that's with only a few lines of code. If I need better performance than that, I can always hand-code, and if that's not good enough, I can resort to assembly.


Dun dun duuuuuuuuuun.

Quote:
Algorithm and the data structures you choose, yes. And of course the implementation of the algorithm matters. Considering the assembly code I see a lot of people write, I unfortunately have more faith in compilers than people like you. Not because compilers do a super-fantastic job, but a lot of people think too highly of themselves.


I'd rather get junk from a narcicist (sp?) who is blinded by themselves than a machine which is blinded completely. At least you can open the eyes of a pompus person, but you can't a machine.

Quote:
Duh. How many percent of your application has bottlenecks, though?


Usually 75%, but that would be a bad estimate, though, considering they're usually small projects like "And the Beat Goes On." I've never done any serious projects with bottle necks.

Quote:
Compilers use heuristics, which tend to work quite well for the majority of your code. For the rest, identified by profiling, you do a little hand-holding or write the stuff manually in assembly. But we're talking a _very_ few percent of critical code, here.


Which ends up resulting in breaking the rules of the compiler, anyway. Then the code isn't completely compiler generated.

Quote:
"Not enough performance" falls into the category of those few percent of the code that matters enough to pay special attention to it. Problem with your macros is that they have fixed register allocation and don't have any previous knowledge of what's on the FPU stack, etc. - a compiler should easily beat trivial cases like that. What you want to do, when optimizing, is take a full algorithm and optimize it properly.


Chances are, if you're using those macro, you're probably using other macro as well. In other words, if you've gone to the length of using the macro, you're probably not worried about what's on the FPU stack because previous operations were probably macros that input stuff and exported the result to a variable immediately.

Quote:
Depends on the kind of code you write. You can do a lot of optimization without a single line of assembly... check some of the strlen algorithms, for instance. Or tricks like representing a huffman tree as an array instead of pointer-based tree. But sure thing, assembly knowledge isn't a bad thing, and I'm not one of the persons that claim assembly is 100% dead.


I know this would be profitable for another topic, but in my opinion, if you have a bottle neck to be optimized, you should go the whole 9 yards with it because there maybe be things outside your app also running which could slow down your bottle neck. As for assembly being dead, obviously not cause we're here arguing it.

Quote:
Ummm... There's language and there's compiler. Compiling something is as simple as "cl myfile.c" or "g++ myfile.cc", depending on your compiler of choice, whether you're doing C/C++, etc. If you want more fancy things, you add some switches, which are pretty well documented. If you feel you have a need for more advanced optimizations switches, you dig into the documentation. Simple as that, when you're writing standard code.


Mmmhm... And the compiler documentation is a shit load of reading. Most compilers (that i've used) set default compilation options all for debug, not optimization. Then you have to worry about pragmas and stuff as well. That's alot of searching and reading. Not my bag of chips.

Quote:
Funny, I found the DirectX documentation pretty fulfilling for my needs - perhaps I was reading different versions than you (DX5,7,. Must admit I haven't done terribly advanced DX things, and mostly stuck with 2D stuff. And I will certainly admit it's a mouthful to digest, especially if you've never done accelerated graphics programming before. I coded plain int13 stuff, allegro and some OpenGL stuff before moving to DirectX, so I guess I was at an advantage, and didn't find it too awful. It's a bit more comfortable in C++ than C, though.


I forget what the topic was, but it was for 8 or 9... i forget which... They've used a bunch of fancy terms and i tried to jump to it right from console.

Quote:
That's too bad. Please accept, then, that you do not have the proper insight to judge C/C++. Yes, I will happily agree that it sucks having to shell out bucks to get a decent understanding of the language (shelling out bucks for a compiler is bad enough - the free GCC is decent enough for more than getting you started, though).


If investment isn't a problem i can't argue with documentation on that point. I've only seen books in my country which is notorious for crappy education.

Quote:
Keep in mind that C/C++ isn't just a toy, it's a professional language used for heavy-duty work. Heck, I'd even argue that you should stay away from it if you're just a hobbyist writing minor projects, since there's easier and faster ways to Get Things Done (TM), and it requires experience to write good code in it (though that does apply to all languages).


I'm a hobbyist who plans on writing free junk in the future to rival with corperate junk. my biggest project (which has been placed on hold) is an instant messenger. It's on hold while i working on learning to display graphics, play sounds (without playsound), and some other things.

Quote:
I'm not exactly a millionare myself, but I manage to pay my bills and still buy a few things here and there. Information wants to be free etc., but I don't think it's a crime awarding people for tearing out a year of their lives and writing up good material.


I feel those books should be written by people out of the kindness of their heart. That way they don't write books just for the money, which would result in a crappy book most likely. Same with programs, but that's just my opinion...

Quote:
Don't take what I write too harshly, but you remind me of a younger and more ignorant me. The kind of person that's the reason a lot of high-level language coders think assembly coders are nuts, and the reason some of us don't mention assembly coding skills unless it's a requirement.


Being probably the youngest here, i can't blame you. But i'm always up for corrections, but give all the pros and cons or it'll turn into a debate. The "return 0" thing for example. Or for a more recent example, this post. Though, i feel that broad topics such as this would end up debate anyway, because the pros and cons are of large numbers. This is probably a bit of a personal subject, but i too do that with alot of people i meet. I feel they are like how i was a few years ago. I often try to stop the mistakes of friends before they happen to them, because of this. You seem to dislike your young version. Perhaps your desire is to stop be from ruing assembly as you blame yourself for doing... Sorry for sounding like a shrink... It's a bad habit of mine, especially if i'm talking about personal matters with some one else at the same time as i type. Off the off topic topic (confusing i'm aware) i'm talking to a girl about teenage-relationships. I think i'll stop now before i traverse too far off the topic.
Post 14 Jun 2007, 02:48
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
Kohlrak wrote:

These tutorials were pre-VC7... That's the sad part. Luckily i lost those tutorials...

Tutorials are often very specific and sucky. You need to find things related to the language rather than the environment.

Kohlrak wrote:

How about professionals that have only used those languages? How about teachers/professors?

If they're professionals, they'll have used more than one language and learned to see more than their tip of their nose. If you've had only zealot professors, I feel genuinely sorry for you, and think that your university might suck. Around here, they teach you a bunch of different languages so you don't get stuck in one mindset.

Kohlrak wrote:

Aside from java, that's true. It's much faster than java, though. If some one wanted to learn an HLL over ASM (i'd still suggest ASM first so if you must use an HLL you can at least work on the bottle neck in it) i would suggest C/C++.

There's not much in the C/C++ language that makes it inherently faster than java, it's mostly in the implementation. But yeah, current java implementations (VM as well as runtime) aren't optimal. Again, don't judge the language ONLY by it's implementation Smile

I still think HLL-first-then-asm or HLL-and-asm is the best combo, assembly is not a beginners language since you get lost in details.

Kohlrak wrote:

The problem is that using those imperfect implimentation too much results in dependency. In the case of need for something faster, your dependency hurts you.

When you need faster, you will know, and you will know what to do. No need to focus on irrelevant details before they become relevant. And current CRT implementations are probably better than what you can muster.

"results in dependency" etc. sounds like the usual FUD.

Kohlrak wrote:

f0dder wrote:

Compilers use heuristics, which tend to work quite well for the majority of your code. For the rest, identified by profiling, you do a little hand-holding or write the stuff manually in assembly. But we're talking a _very_ few percent of critical code, here.

Which ends up resulting in breaking the rules of the compiler, anyway. Then the code isn't completely compiler generated.

Breaking the compiler? No, not unless you're doing very stupid stuff that'd be better done in assembly. I remember a boyer-moore implementation that wasn't far off an assembly implementation, but was still perfectly portable to other platforms. Might've had 5% performance loss on x86, but was portable to even 16bit platforms...

And that was standard code with no compiler-specific tweaks.

Kohlrak wrote:

Chances are, if you're using those macro, you're probably using other macro as well. In other words, if you've gone to the length of using the macro, you're probably not worried about what's on the FPU stack because previous operations were probably macros that input stuff and exported the result to a variable immediately.

And then you're stuck with code that exports temporaries to CPU stack, then reloads to FPU stack... instead of having a few coherent HLL statements that re-uses CPU and FPU registers. Register allocation etc., instead of silly hardcoded rules.

Kohlrak wrote:

I know this would be profitable for another topic, but in my opinion, if you have a bottle neck to be optimized, you should go the whole 9 yards with it because there maybe be things outside your app also running which could slow down your bottle neck. As for assembly being dead, obviously not cause we're here arguing it.

Things outside your application is generally outside your control. Of course you shouldn't think you own the whole CPU (which a bunch of asm programs do), instead you should code to use as little resources as possible (and, in some cases, use as much as you can, but as optimally as you can).

But as for bottlenecks in your applications, those are easy to identify by profiling. And when identified, they can be fixed by optimizing some small portion of code, or (ack!) by rewriting data structures and algorithms on a larger scale.

Kohlrak wrote:

Mmmhm... And the compiler documentation is a shit load of reading. Most compilers (that i've used) set default compilation options all for debug, not optimization. Then you have to worry about pragmas and stuff as well. That's alot of searching and reading. Not my bag of chips.

If you use the IDE, there's a "debug" and "release" setting, which will be sufficient. If you write code, you'll might be using a separate editor, and invoking the compiler from a commandline... and you'll worry about commandline switches when it becomes necessary. If you can't find the necessary documentation, then, blame your compiler vendor. If you're using MSVC, blame yourself.

Kohlrak wrote:

f0dder wrote:

Keep in mind that C/C++ isn't just a toy, it's a professional language used for heavy-duty work. Heck, I'd even argue that you should stay away from it if you're just a hobbyist writing minor projects, since there's easier and faster ways to Get Things Done (TM), and it requires experience to write good code in it (though that does apply to all languages).

I'm a hobbyist who plans on writing free junk in the future to rival with corperate junk. my biggest project (which has been placed on hold) is an instant messenger. It's on hold while i working on learning to display graphics, play sounds (without playsound), and some other things.

Humm, so it's on hold while you learn some extremely trivial things? I wonder how you're going to fare on the more interesting things, namely the protocol and async nature of IM. And why start Yet Another IM, when there's already sevaral projects you could join, of whom you'll never manage to beat a single on?

Kohlrak wrote:

I feel those books should be written by people out of the kindness of their heart. That way they don't write books just for the money, which would result in a crappy book most likely. Same with programs, but that's just my opinion...

Do you have any idea what kind of dedication it takes to write a Real World Book? It's not like you get rich from writing a book... you might get a decent amount of money afterwards, from selling yourself at seminars and whatever, but writing a book requires pulling out a LOT of time and effort from your life.

Same goes for software. But perhaps you think people should build houses and cars for free, too. Just because software is virtual and books are easy to copy doesn't mean people haven't spent a shitload of time on it.

Kohlrak wrote:

The "return 0" thing for example.

return 0 vs. whatever else is pretty academic, but there's no sane reason not to follow standards. While it's extremely unlikely, some implementation might end up returning STILL_ACTIVE (and actually, ought to Razz) for undefined return codes... which would fuck up everything. Same goes for "ret" vs. "ExitProcess". You have so slight gains by being non-standard (wouldn't even be measurable on a 386) that you ought to be punished for not being.

Doesn't really matter anyway, you'll come around eventually - or perish Smile
Post 14 Jun 2007, 03:32
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
Quote:
Tutorials are often very specific and sucky. You need to find things related to the language rather than the environment.


Wish that were simple. I'm decent with the language, it's actually doing stuff with the language.

Quote:
If they're professionals, they'll have used more than one language and learned to see more than their tip of their nose. If you've had only zealot professors, I feel genuinely sorry for you, and think that your university might suck. Around here, they teach you a bunch of different languages so you don't get stuck in one mindset.


Most of the people i've dealt with in the past avoid ASM and stick with a bunch of HLLs.

Quote:
There's not much in the C/C++ language that makes it inherently faster than java, it's mostly in the implementation. But yeah, current java implementations (VM as well as runtime) aren't optimal. Again, don't judge the language ONLY by it's implementation


Not in the language. But C/C++ implimentation will always rule over because all the things supporting java are based on the JVM. Take away teh JVM (which C/C++ dosn't use) and you loose all java advertises, not that it's completely cross platform anyway. Java's really only good for applets in my book.

Quote:
I still think HLL-first-then-asm or HLL-and-asm is the best combo, assembly is not a beginners language since you get lost in details.


Indeed.

Quote:
When you need faster, you will know, and you will know what to do. No need to focus on irrelevant details before they become relevant. And current CRT implementations are probably better than what you can muster.


Just cause you know ti's not the best solution dosn't mean your habit will prevent you from providing another solution.

Quote:
Breaking the compiler? No, not unless you're doing very stupid stuff that'd be better done in assembly. I remember a boyer-moore implementation that wasn't far off an assembly implementation, but was still perfectly portable to other platforms. Might've had 5% performance loss on x86, but was portable to even 16bit platforms...

And that was standard code with no compiler-specific tweaks.


Must be daaaaaaamn good. Though i find that any optimization that's worht doing, you my as well use the compiler's ASM keyword, which many probably do, though it seems to vary from compiler to compiler.

Quote:
And then you're stuck with code that exports temporaries to CPU stack, then reloads to FPU stack... instead of having a few coherent HLL statements that re-uses CPU and FPU registers. Register allocation etc., instead of silly hardcoded rules.


If you like the stack so much you could always use a pointer to the stack, i forget which register it is though... Though, i personally have a vendetta against the stack for anything other than function calls. But it's all a matter of preferance.

Quote:
Things outside your application is generally outside your control. Of course you shouldn't think you own the whole CPU (which a bunch of asm programs do), instead you should code to use as little resources as possible (and, in some cases, use as much as you can, but as optimally as you can).


Oh indeed. Usually i go for speed over size for bottle necks, and size optimization everywhere else. But that's just my way of doing things.

Quote:
But as for bottlenecks in your applications, those are easy to identify by profiling. And when identified, they can be fixed by optimizing some small portion of code, or (ack!) by rewriting data structures and algorithms on a larger scale.


I find it much easier to write teh whole thing in ASm, but once again. That's my way.

Quote:
If you use the IDE, there's a "debug" and "release" setting, which will be sufficient. If you write code, you'll might be using a separate editor, and invoking the compiler from a commandline... and you'll worry about commandline switches when it becomes necessary. If you can't find the necessary documentation, then, blame your compiler vendor. If you're using MSVC, blame yourself.


I had a specific argument for MSVC that is differnet from my excuse for other compilers, but it's been so long since i've used it for anything other than trying to compile and reorganized nehe's tuts, i've since forgotten. Though other than that, i can sit and blame the compiler all day.

Quote:
Humm, so it's on hold while you learn some extremely trivial things? I wonder how you're going to fare on the more interesting things, namely the protocol and async nature of IM. And why start Yet Another IM, when there's already sevaral projects you could join, of whom you'll never manage to beat a single on?


The thing about my instant messenger is that it'll be a bit different from the usual services. And those things aren't so trivial for some one trying to learn by converting and optimizing all in one. I was hopeing to use OpenGL and converting NeHe's junk to fasm isn't so easy for me. Especially cause i keep trying to get ahead of myself and rewrite the whole code from scratch instead of compiling first and then reorganize it then converting it to asm. But these subjects are trivial. Though, i'm really questioning if TCP is really wise for what i'm after. Running with TCP will result in a heck of alot of threads in the long run. So i'll have to learn more than just TCP before i continue as well, but i have a pretty good idea on how i'm going to handle things like asyncronizatioin.

Quote:
Do you have any idea what kind of dedication it takes to write a Real World Book? It's not like you get rich from writing a book... you might get a decent amount of money afterwards, from selling yourself at seminars and whatever, but writing a book requires pulling out a LOT of time and effort from your life.


True, which means it has to be a very loving person.

Quote:
Same goes for software. But perhaps you think people should build houses and cars for free, too. Just because software is virtual and books are easy to copy doesn't mean people haven't spent a shitload of time on it.


i don't mind houses and cars so much because they have building codes in many places. There aren't any laws making people write decent books or programs, on the other hand. At least, none that i've seen.

Quote:
return 0 vs. whatever else is pretty academic, but there's no sane reason not to follow standards. While it's extremely unlikely, some implementation might end up returning STILL_ACTIVE (and actually, ought to ) for undefined return codes... which would fuck up everything. Same goes for "ret" vs. "ExitProcess". You have so slight gains by being non-standard (wouldn't even be measurable on a 386) that you ought to be punished for not being.


Well i still remember debating over that. And though incredibly stupid, it was the closest to recent example i could think of. Also the first thing that came to mind.

Quote:
Doesn't really matter anyway, you'll come around eventually - or perish


Oh, i'm bound to perish. Though i'm not so sure it'll be the result of my coding habits. XD
Post 14 Jun 2007, 06:47
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
Kohlrak wrote:

Not in the language. But C/C++ implimentation will always rule over because all the things supporting java are based on the JVM. Take away teh JVM (which C/C++ dosn't use) and you loose all java advertises, not that it's completely cross platform anyway. Java's really only good for applets in my book.

There isn't really anything to stop somebody from making a non-JVM implementation of JAVA. The GNU/GCC people are working on it, although it does seem a bit hacky. There's "JAVA CPUs" as well, although I guess it's probably an ARM or whatever with a JVM in flash ROM.

The JAVA language itself seems fine enough to me anyway, it's the implementation and the class libraries that's the problem. And with JAVA, it's a bit hard avoiding that Smile

Kohlrak wrote:

f0dder wrote:

Breaking the compiler? No, not unless you're doing very stupid stuff that'd be better done in assembly. I remember a boyer-moore implementation that wasn't far off an assembly implementation, but was still perfectly portable to other platforms. Might've had 5% performance loss on x86, but was portable to even 16bit platforms...

And that was standard code with no compiler-specific tweaks.

Must be daaaaaaamn good. Though i find that any optimization that's worht doing, you my as well use the compiler's ASM keyword, which many probably do, though it seems to vary from compiler to compiler.

No, it was pretty straightforward code actually - the compiler just happened to do a pretty decent job. I stay away from inline assembly anyway, when I do need assembly it's enough that having it in external .asm isn't a bother, and it's more portable that way (both different platforms as well as different compilers on one platform).

Kohlrak wrote:

If you like the stack so much you could always use a pointer to the stack, i forget which register it is though... Though, i personally have a vendetta against the stack for anything other than function calls. But it's all a matter of preferance.

You're the one that proposed store-and-reload, not me Smile

The stack is fine anyway, you're pretty sure it's going to be in L1 cache since it's used all the time, and you need it if you're going to write thread-safe functions.

Still, no reason to spill to stack if not necessary, but that's what you easily end up doing if you're using static macro building blocks, instead of a dynamic register-allocating compiler.

Kohlrak wrote:

Oh indeed. Usually i go for speed over size for bottle necks, and size optimization everywhere else. But that's just my way of doing things.

And that's how it should be done. For "the rest of the code" speed usually doesn't matter, so might as well keep size down (optimized code tends to be larger) to save on precious processor cache. Doesn't matter much memory and disk space wise, although it can matter a bit if you're writing code that'll run sevaral hundred instances on a terminal server Smile

Kohlrak wrote:

The thing about my instant messenger is that it'll be a bit different from the usual services. And those things aren't so trivial for some one trying to learn by converting and optimizing all in one. I was hopeing to use OpenGL and converting NeHe's junk to fasm isn't so easy for me.

I hope you aren't going to use OpenGL for instant messaging? O_o

Iirc NeHe's code is pretty straightforward and relatively clean, so it shouldn't be a problem converting it to assembly... API-heavy code can often be translated more or less line per line.

Kohlrak wrote:

Though, i'm really questioning if TCP is really wise for what i'm after. Running with TCP will result in a heck of alot of threads in the long run. So i'll have to learn more than just TCP before i continue as well, but i have a pretty good idea on how i'm going to handle things like asyncronizatioin.

You don't need a thread per connection just because you're doing TCP, look up the async winsock calls. And please don't use the WM_* based WSAAsyncSelect() method, it sucks. A thread per socket wouldn't be bad for an instant-messaging client anyway, since you're not going to have a lot of connections, and windows handles threads pretty well... doing it async is still more proper, though.
Post 14 Jun 2007, 11:27
View user's profile Send private message Visit poster's website Reply with quote
DustWolf



Joined: 26 Jan 2006
Posts: 373
Location: Ljubljana, Slovenia
f0dder wrote:
There isn't really anything to stop somebody from making a non-JVM implementation of JAVA. The GNU/GCC people are working on it, although it does seem a bit hacky. There's "JAVA CPUs" as well, although I guess it's probably an ARM or whatever with a JVM in flash ROM.

The JAVA language itself seems fine enough to me anyway, it's the implementation and the class libraries that's the problem. And with JAVA, it's a bit hard avoiding that Smile


If I may make a little sub-thread here... Are you saying it doesn't matter if the language is made from an optimal processor architecture or the other way around?

Because I always thought the point of programming was to make a specific device do something, not to make an instrunction set which defines what a device needs to be like. Rolling Eyes
Post 14 Jun 2007, 12:09
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
DustWolf: not sure I understand what you're asking Smile. But a couple of things... you don't necessarily need to do implement java with a VM, and you don't necessarily need to implement it with the bytecode format SUN uses. Dunno why they've made those "java CPUs" anyway, I wouldn't use it for any realtime task...
Post 14 Jun 2007, 13:28
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
Quote:
There isn't really anything to stop somebody from making a non-JVM implementation of JAVA. The GNU/GCC people are working on it, although it does seem a bit hacky. There's "JAVA CPUs" as well, although I guess it's probably an ARM or whatever with a JVM in flash ROM.


I've thought of ARM development already... Looks interesting considering the platforms. I might want to get ahold of you sometime about that one.

Quote:
The JAVA language itself seems fine enough to me anyway, it's the implementation and the class libraries that's the problem. And with JAVA, it's a bit hard avoiding that


Aye, it's that implimentation. What's funny is when people get the compilers for java and assume that compiling their code will protect it. You can very easily convert it right back to it's HLL form. Saw many programs to do it, though i've never tried it. What's really eerie is how some java programs are stored in EXE files... I wonder what the point is... They're still using the jvm.

Quote:
No, it was pretty straightforward code actually - the compiler just happened to do a pretty decent job. I stay away from inline assembly anyway, when I do need assembly it's enough that having it in external .asm isn't a bother, and it's more portable that way (both different platforms as well as different compilers on one platform).


Hm...

Quote:
The stack is fine anyway, you're pretty sure it's going to be in L1 cache since it's used all the time, and you need it if you're going to write thread-safe functions.


Depends on what goes on in your threads... And assuming they all need seperate memory. If they don't, you are probably just needing stop functions.

Quote:
Still, no reason to spill to stack if not necessary, but that's what you easily end up doing if you're using static macro building blocks, instead of a dynamic register-allocating compiler.


Unless it sets off some kind of overflow thing that i don't know about, overflowing it shouldn't do anything except loose temp the unused tempdata that wasn't popped.

Quote:
And that's how it should be done. For "the rest of the code" speed usually doesn't matter, so might as well keep size down (optimized code tends to be larger) to save on precious processor cache. Doesn't matter much memory and disk space wise, although it can matter a bit if you're writing code that'll run sevaral hundred instances on a terminal server


At least we agree on something. lol

Quote:
hope you aren't going to use OpenGL for instant messaging? O_o


It's going to be user-friendly as well. Most im services (and it seems most users have grown attatched to this rather pointless feature so i must include it) have a "display picture" feature. Of course i could use something else, but i figured allowing developers to "invent" 3d icons would also give this program a bit of an edge. Since most programs usually don't get a big start, i figured i'd need a bunch of fancy bells and whistles to give it a push or it's not gonna fly out of it's nest.

Quote:
Iirc NeHe's code is pretty straightforward and relatively clean, so it shouldn't be a problem converting it to assembly... API-heavy code can often be translated more or less line per line.


As always, i'm just trying to avoid glaux because i heard it might not be installed on all machines. The examples that don't use glaux are just mixed up all over the place. Though, the only real reson i havn't got that tut figured out by now is because i've been procrastinating for the past week or two.

Quote:
You don't need a thread per connection just because you're doing TCP, look up the async winsock calls. And please don't use the WM_* based WSAAsyncSelect() method, it sucks. A thread per socket wouldn't be bad for an instant-messaging client anyway, since you're not going to have a lot of connections, and windows handles threads pretty well... doing it async is still more proper, though.


If you've seen how many IM windows i have open half the time... Worse yet would be how many i hear some of my female friends complain they have open... Worse part yet is that i plan on doing it client to client with the seperate server being optional (which i'm also aware will cause some friction, but in the long run it'll be worht it if people go for it).
Post 14 Jun 2007, 17: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
Kohlrak wrote:

I've thought of ARM development already... Looks interesting considering the platforms. I might want to get ahold of you sometime about that one.

Unfortunately I haven't done any ARM development, although I did get a developer CD from them. Seems like an interesting set of platforms, though. I guess my brothers don't use their Gameboy Advance anymore, might be fun toying around with that. Would need to purchase some flashable cartridge and stuff, though... so I guess an emulator is easier.

I think vid has been doing some ARM development?

Kohlrak wrote:

Aye, it's that implimentation. What's funny is when people get the compilers for java and assume that compiling their code will protect it. You can very easily convert it right back to it's HLL form.

You don't get the exact HLL code back, and there's obfuscators to mess up method and variable names. But yes, it's a lot easier going JVM bytecode -> readble source than x86 exe -> readable source, because of the way the JVM bytecode is constructed. I daresay that it's stackbased rather than register based also helps a lot.

Kohlrak wrote:

Saw many programs to do it, though i've never tried it. What's really eerie is how some java programs are stored in EXE files... I wonder what the point is... They're still using the jvm.

.exe looks pretty than .jar or whatever, and won't confuse people as much Razz - there might be some other points as well, dunno.


Kohlrak wrote:

f0dder wrote:

The stack is fine anyway, you're pretty sure it's going to be in L1 cache since it's used all the time, and you need it if you're going to write thread-safe functions.

Depends on what goes on in your threads... And assuming they all need seperate memory. If they don't, you are probably just needing stop functions.

Well, what I meant was that you can't really use global storage for your threads, unless you synchronize access to it (which easily kills performance). Stack is your friend Smile

Kohlrak wrote:

It's going to be user-friendly as well. Most im services (and it seems most users have grown attatched to this rather pointless feature so i must include it) have a "display picture" feature. Of course i could use something else, but i figured allowing developers to "invent" 3d icons would also give this program a bit of an edge. Since most programs usually don't get a big start, i figured i'd need a bunch of fancy bells and whistles to give it a push or it's not gonna fly out of it's nest.

Eeek, featuritis Smile

I prefer plain and simple things - www.miranda-im.org is pretty nice.

Kohlrak wrote:

If you've seen how many IM windows i have open half the time... Worse yet would be how many i hear some of my female friends complain they have open... Worse part yet is that i plan on doing it client to client with the seperate server being optional (which i'm also aware will cause some friction, but in the long run it'll be worht it if people go for it).

Thread-wise, not even 100 open IM windows would be a problem, really, since the threads will be sleeping most of the time. I can't remember the per-process thread limit, but it's in the thousands range.

Still, doing it properly with async sockets is better. The event-based socket model works pretty great. It's how µTorrent handles it's connections as well.
Post 14 Jun 2007, 23:38
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
Quote:
Unfortunately I haven't done any ARM development, although I did get a developer CD from them. Seems like an interesting set of platforms, though. I guess my brothers don't use their Gameboy Advance anymore, might be fun toying around with that. Would need to purchase some flashable cartridge and stuff, though... so I guess an emulator is easier.


It's the DS that interests me. Tough part about that is i looked and it has 2 processors running side by side. I would imagin 2 processors would be a pain in the but to code for at once.

Quote:
.exe looks pretty than .jar or whatever, and won't confuse people as much - there might be some other points as well, dunno.


Still just as slow.

Quote:
Well, what I meant was that you can't really use global storage for your threads, unless you synchronize access to it (which easily kills performance). Stack is your friend


Depending on how you do it you could still get away from the stack with dynamic allocation, but that would just result in one nasty take up of space.

Quote:
Eeek, featuritis


Ah, but most people (for some unkown reson) love bells and whistles. They're my target group, and until they wisen up, it's alot of features.

Quote:
Thread-wise, not even 100 open IM windows would be a problem, really, since the threads will be sleeping most of the time. I can't remember the per-process thread limit, but it's in the thousands range.

Still, doing it properly with async sockets is better. The event-based socket model works pretty great. It's how µTorrent handles it's connections as well.


One way to find out... And i'll probably still need to a bunch of threads per window anyway, that way if one window freezes because of a glitch, they can keep the rest of their windows running fine and report the bug to me for fixing. But yea, i'll consider the async. I don't have much in the department of winsocks stuff though. Madwizard's junk was a bit incomplete. So i have alot of junk to research, but it's all minor junk.
Post 15 Jun 2007, 00:01
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
Kohlrak wrote:

It's the DS that interests me. Tough part about that is i looked and it has 2 processors running side by side. I would imagin 2 processors would be a pain in the but to code for at once.

Not necessarily... coding for multi-cpu (ie., SMP or dual-core or whatever x86) isn't too bad, you do need to be careful about synchronizing access to global data structures, and other things.

Other architectures have specialized CPUs, which is why both C=64 and Amiga were so powerful (for their time) even though the main CPUs were relatively limited.

It does become relatively bitchy, or so I've heard, for wacky architectures like the playstation - all three of them have been pretty different from what other consoles look like. Read up on the PS3, it sounds pretty damn interesting. Will take a while before developers learn how to harness all that power, though.

Kohlrak wrote:

f0dder wrote:

.exe looks pretty than .jar or whatever, and won't confuse people as much - there might be some other points as well, dunno.

Still just as slow.

Yup.

Kohlrak wrote:

Depending on how you do it you could still get away from the stack with dynamic allocation, but that would just result in one nasty take up of space.

Dynamic (heap) allocation is a lot slower than "sub esp, xx" though. And each thread will always have at least 4kb stack, so you might as well use the stack for smallish allocations.

Kohlrak wrote:

One way to find out... And i'll probably still need to a bunch of threads per window anyway, that way if one window freezes because of a glitch, they can keep the rest of their windows running fine and report the bug to me for fixing. But yea, i'll consider the async. I don't have much in the department of winsocks stuff though. Madwizard's junk was a bit incomplete. So i have alot of junk to research, but it's all minor junk.

MadWizard's stuff isn't junk - it's some of the better stuff available on winsock. Threads won't help you too much wrt. glitches of that kind... you still need a synchroneous message-pump, and it's glitches in message processing that usually locks up applications.
Post 15 Jun 2007, 00:15
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3  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-2019, Tomasz Grysztar.

Powered by rwasa.