Coder's Hang-out

[pkt-zer0]

Not as fast as you think... lol 1ghz... based on my 2.5 i'd have to say that's about 1000 increments and printing them out per second.

Actually, faster. Try repeating a single operation in a loop (without printing it to screen), and timing it with GetTickCount, maybe. It IS fast, believe me. I mean, C code executes in virtually 0 seconds, unless there's something involving a peripheral (screen, harddrive). So yeah, the CPU and memory are hella fast.

Is it commented at all? And is it filled with a bunch of nonsence global variablse like "_t" then have a "_T" then have "_Tc" and "_tC" and another "_TC"? X'D

Well, it's an open source project, meaning anyone could modify it, so yeah, it's pretty well commented. It is more readable (and more compact) then most code I produce, anyway.

[kohlrak]

Actually, faster. Try repeating a single operation in a loop (without printing it to screen), and timing it with GetTickCount, maybe. It IS fast, believe me. I mean, C code executes in virtually 0 seconds, unless there's something involving a peripheral (screen, harddrive). So yeah, the CPU and memory are hella fast.

You forget, when you're talkin' FPS and stuffs, ick... A second is like forever, especially if you're like me with ADHD. lol

Well, it's an open source project, meaning anyone could modify it, so yeah, it's pretty well commented. It is more readable (and more compact) then most code I produce, anyway.

The more compact, the better... well.. the less code the better. lol

Another good one, how much does calling a function slow down a computer verses a macros? And how much more space does it take on the compy? And! Another one, how much more does it take to call from a DLL?

As for pointies... I have a good challenge for you if you ever get bored PKT. Write a source code that when compilled and run, it'll copy itself from the ram and write it to a file and save it as ".ram". Chances are it'll crash alot... but i have a funny feeling we might get something intresting from it... Who knows what we'd learn if it succeeded?

EDIT: Reminds me of looking at the direct X API. lol

EDIT2: Hm... I wonder how you can really output anything to the screen if C++ has no functions of it's own... And i wonder how a hello program would look in ASM... i got a disassembler here but it only opens ".com" files. lol

EDIT3: Holy crap... I managed to open up an exe file in this thing and... o.o Dude, it looks like somthing i once saw in visual C++ 6.0 when debugging a file one time...

[pkt-zer0]

You forget, when you're talkin' FPS and stuffs, ick... A second is like forever, especially if you're like me with ADHD. lol

Yeah, but it makes a difference, computing 1000 of 10 billion operations a second. If you raise the times you execute the loop high enough, it will take more than a second. But it's interesting to see how high it goes.

Another good one, how much does calling a function slow down a computer verses a macros? And how much more space does it take on the compy? And! Another one, how much more does it take to call from a DLL?

Macros are simply text replaced with other text in the code, during compile time. So it doesn't slow anything at all, only what's executed within. With functions, the return address and values go on the stack, so your only problem would be that filling, and the program crashing. Don't' worry, it's pretty large, for this purpose at least, but going into infinite recursion crashes it, recursion itself eats up pretty much of the stack, as well. With the stack being the part of the memory that's accessed with the greatest speed, that's not quite good.
DLLs are Dynamically Linked Libraries, meaning they get linked run-time, more precisely on start. I don't think that's much slower (obviously you'll get smaller executable sizes than including the libraries in the EXE itself), but version incompatibilities could be a problem sometimes.

As for pointies... I have a good challenge for you if you ever get bored PKT. Write a source code that when compilled and run, it'll copy itself from the ram and write it to a file and save it as ".ram". Chances are it'll crash alot... but i have a funny feeling we might get something intresting from it... Who knows what we'd learn if it succeeded?

I'm not sure if Windows would let me do that, kinda like it wouldn't let me access the video memory directly, still, worth a try. Anyway, the code is obviously there in the EXE file in some form. I'm not sure if it's self-extracting, or uncompressed.
Download Links:
Links are hidden from guests. Please register to be able to view these links. Arrgh, doesn't work. Tried copying memory from an array containing a sample string, and it wouldn't let me go much further than the end of the array. Gotta learn the Windows API sometime.

EDIT2: Hm... I wonder how you can really output anything to the screen if C++ has no functions of it's own...

C was designed for portability. Since not all computers even have a screen, you don't get standard methods for output. The good thing is you could even code for whatever weird sort of terminal you'd like.

EDIT3: Holy crap... I managed to open up an exe file in this thing and... o.o Dude, it looks like somthing i once saw in visual C++ 6.0 when debugging a file one time...

Yep, Assembler is nice. Even nicer if you understand what things do.
BTW, here's some code a guy I know wrote. He's pretty into low-level coding, so yeah. Beware.

[kohlrak]

Macros are simply text replaced with other text in the code, during compile time. So it doesn't slow anything at all, only what's executed within. With functions, the return address and values go on the stack, so your only problem would be that filling, and the program crashing. Don't' worry, it's pretty large, for this purpose at least, but going into infinite recursion crashes it, recursion itself eats up pretty much of the stack, as well. With the stack being the part of the memory that's accessed with the greatest speed, that's not quite good.
DLLs are Dynamically Linked Libraries, meaning they get linked run-time, more precisely on start. I don't think that's much slower (obviously you'll get smaller executable sizes than including the libraries in the EXE itself), but version incompatibilities could be a problem sometimes.

So in other words, writing functions themselves rather than macros wouldn't change the speed any, just risk chance of crashing.. What do you me recursion? In otherwords, are you talking about calling the function within itself or are you talking about calling it from wherever? (If you mean calling from wherever, i'll just use the while loop and the debug runtime and find the exact number. lol)

I'm not sure if Windows would let me do that, kinda like it wouldn't let me access the video memory directly, still, worth a try. Anyway, the code is obviously there in the EXE file in some form. I'm not sure if it's self-extracting, or uncompressed.
Download Links:
Links are hidden from guests. Please register to be able to view these links. Arrgh, doesn't work. Tried copying memory from an array containing a sample string, and it wouldn't let me go much further than the end of the array. Gotta learn the Windows API sometime.

lol, we all should... But the winapi is more than just an API, it's pratically a whole new language in itself, and from what i've seen the vocabulary and such are bigger and such than C++ itself. lol

C was designed for portability. Since not all computers even have a screen, you don't get standard methods for output. The good thing is you could even code for whatever weird sort of terminal you'd like.

Yea, but, it would require that somthing other than C++ was to do stuff like output. Something foreign would have to be thrown in there. Weather it be a call to a non C++ dll or so forth.

Yep, Assembler is nice. Even nicer if you understand what things do.
BTW, here's some code a guy I know wrote. He's pretty into low-level coding, so yeah. Beware.

Oh yea, could you imagin all the nice things we could do. The biggest problem we'd face is figuring out all we need to run the programs on a specific operating system. I've actually opened some of the prebuild files that come after compiling the script. With windows compilers, actually, there is C++ code added to it. I thought i saw one of the files was called runtime. Alot of stuff we really don't see. and i have a theory. That since C++ (pretty sure it is) gets converted to assembly before it's compiled (now where that data is stored, we dont' know) we not only have assemblers and maybe disassemblers on our computers with our compilers, but we may also be able to fix many problems we have with our problems. Liiiiike, the fact that ints are 4 bytest, perhaps just finding that information (probably stored in the ram while it compiles) we could edit how big datatypes are and more than just that. Another little trick, with assembly, we could write huge projects, then delete the garbage with a disassembler. I'm sure there is lots of code in the C++ program files that we have that most of it isn't even needed or used. Could speed up things quite a bit and maybe take them to the same speed as assembly programs, only that we didn't have to type in all the ASM junk. We could just open the ASM file with notepad, highlight and backspace out all the funk and it'd work better. If this is true, we could very well speed up some of these games we play on our computer, such as halo or call of duty or such. Then being wonderful coders we are, release a program that would cut out all that junk, or the optimized file.

EDIT: I just found out 1 good reson to use printf() over "cout <<". lol cout ALWAYS prints1 char at a time. That means cout is slower, how did i find this out and that printf dosn't? I used my thread project. Now i like threads, it's just i wish the so called mutex would actually work. They have things out there to keep threads from corrupting (or at least it should), but they don't work. Just take up more code space. lol

[pkt-zer0]

So in other words, writing functions themselves rather than macros wouldn't change the speed any, just risk chance of crashing.. What do you me recursion? In otherwords, are you talking about calling the function within itself or are you talking about calling it from wherever? (If you mean calling from wherever, i'll just use the while loop and the debug runtime and find the exact number. lol)

Not exactly. Macros are as fast as the code contained within them. Since that's all they are.
Functions, however, take up memory additional to that what's used within, because the function that called them will have to store where to continue executing the code.
Recursion is calling the function from within itself, yeah. Like the common

int factorial( int n ) return (n<=1) ? 1 : n*factorial(n-1);

For calculating n! . One-liners win.

Yea, but, it would require that somthing other than C++ was to do stuff like output. Something foreign would have to be thrown in there. Weather it be a call to a non C++ dll or so forth.

Exactly what I said. That's why it's portable. Had there been default functions for those thrown in, compilers would be pretty freaking huge, with a gazillion of libraries.

That since C++ (pretty sure it is) gets converted to assembly before it's compiled (now where that data is stored, we dont' know) we not only have assemblers and maybe disassemblers on our computers with our compilers, but we may also be able to fix many problems we have with our problems.

There is an option in certain compilers to dump the code to file during different parts of the compilation, for example after the macros have been replaced, or after all of it's been converted to assembler. But no, don't try to optimize it, it's already written pretty well, by people who specialize in that sort of stuff. You're always free to write your own compiler, sometime in the future.

Liiiiike, the fact that ints are 4 bytest, perhaps just finding that information (probably stored in the ram while it compiles) we could edit how big datatypes are and more than just that.

The size of integers have nothing to do with assembler, but rather, the compiler. In C, it's implementation-defined, meaning that there's a pre-defined value in the compiler that stores the size of integers. Yeah, it can be changed, you just have to build your own compiler. gcc is open source, so that might be a way if you really want to mess with that.
Ints are 4 bytes because they're optimized for 32bit CPUs, obviously.

Another little trick, with assembly, we could write huge projects, then delete the garbage with a disassembler. I'm sure there is lots of code in the C++ program files that we have that most of it isn't even needed or used. Could speed up things quite a bit and maybe take them to the same speed as assembly programs, only that we didn't have to type in all the ASM junk. We could just open the ASM file with notepad, highlight and backspace out all the funk and it'd work better. If this is true, we could very well speed up some of these games we play on our computer, such as halo or call of duty or such. Then being wonderful coders we are, release a program that would cut out all that junk, or the optimized file.

Just removing random stuff doesn't optimize things. Sure, it makes it faster, but unless you're replacing those things with something else, it won't work. Anyway, this is a 'been-there-done-that' sort of situation. Where speed is critical, people prefer to use highly optimized assembler code. Though this is the smaller part of the speed issue.

EDIT: I just found out 1 good reson to use printf() over "cout <<". lol cout ALWAYS prints1 char at a time. That means cout is slower, how did i find this out and that printf dosn't? I used my thread project. Now i like threads, it's just i wish the so called mutex would actually work. They have things out there to keep threads from corrupting (or at least it should), but they don't work. Just take up more code space. lol

C++ was always slower than C, but more safe, due to the object oriented approach. The good thing is that you won't break a program by misusing an object, simply because the object itself won't let you. You can easily kill off variables by making a simple mistake while reading stuff with scanf, however.

[kohlrak]

Not exactly. Macros are as fast as the code contained within them. Since that's all they are.
Functions, however, take up memory additional to that what's used within, because the function that called them will have to store where to continue executing the code.
Recursion is calling the function from within itself, yeah. Like the common

int factorial( int n ) return (n<=1) ? 1 : n*factorial(n-1);

For calculating n! . One-liners win.

So, basically, as long as i don't have a function call itself, i don't have to worry about anything, right?

Exactly what I said. That's why it's portable. Had there been default functions for those thrown in, compilers would be pretty freaking huge, with a gazillion of libraries.

Yea, but somthing has to come from some where. This means, something non C++ or non C has to be hidden some where. I'm a bit curious how they got this forign stuff in without any errors...

There is an option in certain compilers to dump the code to file during different parts of the compilation, for example after the macros have been replaced, or after all of it's been converted to assembler. But no, don't try to optimize it, it's already written pretty well, by people who specialize in that sort of stuff. You're always free to write your own compiler, sometime in the future.

Like who? You know it's pretty well not optimized if microsoft written it. No one knows assembly so no one'd know, yet using Visual C++ is the best choice for windows, because of all the APIs for visual C++ only, but then we're once again stuck with unoptimized crap.

The size of integers have nothing to do with assembler, but rather, the compiler. In C, it's implementation-defined, meaning that there's a pre-defined value in the compiler that stores the size of integers. Yeah, it can be changed, you just have to build your own compiler. gcc is open source, so that might be a way if you really want to mess with that.
Ints are 4 bytes because they're optimized for 32bit CPUs, obviously.

Well, i think that stuff would be built in the ASM code, though, since ASM is direct processor code.

Just removing random stuff doesn't optimize things. Sure, it makes it faster, but unless you're replacing those things with something else, it won't work. Anyway, this is a 'been-there-done-that' sort of situation. Where speed is critical, people prefer to use highly optimized assembler code. Though this is the smaller part of the speed issue.

Well, like i said, i'm sure there is a bunch of junk in there that isn't even used. If it's not used, it's not needed and can be safely cut out. Alot of the exception codes that you can see with a hex editor which is put into the code, could easily be cured. If you have your own code in you own program with exceptions because you need it to be a certain range, why have a set of exception checkers and such that check for values over your ranges in both directions? In other words, there is stuff in there that protects code from going too high, but if you have an if statement or such that handles the thing for another value, isn't that exception handle of the higher value worhtless? Wouldn't that junk be worth cutting out and just kill everything that depends on that code and the dependencies of that. No adding, just removing a heck of a lot, and depending how often junk like that is called, could put it at the same speed as ASM code. Plus dramatically cut down on the mem needed.

C++ was always slower than C, but more safe, due to the object oriented approach. The good thing is that you won't break a program by misusing an object, simply because the object itself won't let you. You can easily kill off variables by making a simple mistake while reading stuff with scanf, however.

Thing is, i was using a C++ compiler. And objects don't really have that protection that you think they do. I crash all the time, especially cause string can't be initialized. I'm guessing "cout <<" was horribly coded with a while loop and a call to printf or something of the sort. And i thought C was object oriented. I thought anything with functions was object oriented. And heck, aren't structs mearly C's way of calling objects similar to C++ only without operator overloading?

[pkt-zer0]

So, basically, as long as i don't have a function call itself, i don't have to worry about anything, right?

Right. There always might be exceptions though, but it's not typical that 16000 functions are called at the same time, unless you did something very wrong.

Yea, but somthing has to come from some where. This means, something non C++ or non C has to be hidden some where. I'm a bit curious how they got this forign stuff in without any errors...

That's where standards and APIs and drivers come in. They just do the stuff, so you should't have to care about how it's done. It's just done, somehow.

Like who? You know it's pretty well not optimized if microsoft written it. No one knows assembly so no one'd know, yet using Visual C++ is the best choice for windows, because of all the APIs for visual C++ only, but then we're once again stuck with unoptimized crap.

Get gcc then, it's open source. Meaning that anyone that found anything that was worth improving, did so. Resulting in great speed/stability/reliability/whatever. Also, not all APIs are Visual C++ only. OpenGL and glut (things I used for graphics and input) both work perfectly well under Linux, too. But I agree, there are far too many Win-only stuff.

Well, i think that stuff would be built in the ASM code, though, since ASM is direct processor code.

Yes, ASM is direct processor code. What does that have to do with how large memory blocks are assigned to an individual variable type? Nothing.

Well, like i said, i'm sure there is a bunch of junk in there that isn't even used. If it's not used, it's not needed and can be safely cut out. Alot of the exception codes that you can see with a hex editor which is put into the code, could easily be cured. If you have your own code in you own program with exceptions because you need it to be a certain range, why have a set of exception checkers and such that check for values over your ranges in both directions? In other words, there is stuff in there that protects code from going too high, but if you have an if statement or such that handles the thing for another value, isn't that exception handle of the higher value worhtless? Wouldn't that junk be worth cutting out and just kill everything that depends on that code and the dependencies of that. No adding, just removing a heck of a lot, and depending how often junk like that is called, could put it at the same speed as ASM code. Plus dramatically cut down on the mem needed.

Yeah, optimizing. If something seems slow, code your version of it, to see if it's faster. If it IS, use it, if not, revert. However...
Have you ever checked out Cassini, the "Open Source" Saturn Emulator? Those fools just disassembled the code, and put the ~2MB of assembler into a text file. See if you can improve it in a hundred million years.
Truly, ASM is not pleasant to the eye in the case of larger programs. It is good for making a select few functions smaller/faster, though, but you don't need a disassembler for that.

Thing is, i was using a C++ compiler. And objects don't really have that protection that you think they do. I crash all the time, especially cause string can't be initialized. I'm guessing "cout <<" was horribly coded with a while loop and a call to printf or something of the sort. And i thought C was object oriented. I thought anything with functions was object oriented. And heck, aren't structs mearly C's way of calling objects similar to C++ only without operator overloading?

Object orientation is an approach to programming, a programming method itself, alternative to structured programming, it has nothing to do with the actual datatypes themselves.
In structured programming, you make loops and functions to handle the data.
In object oriented programming, you make objects that are autonomous in some way, and have them go at it. The thing is that here the data is contained in the objects themselves, and is not manipulated from the outside. The objects re-assign their inner variables according to various instructions you may give them, and then behave accordingly. So, you could have a Player object, with a Jump method, that would make it jump, without you having to care about the exact details (collision, velocity, animation).
BTW, the difference between structs and classes in C++ is that structs data fields default to public, whereas classes' default to private. There is no private/public distinction in C, therefore no need for classes.