Thread: Found out why Oblivion slowed down

  1. #16
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Also, it is not faster than Java bytecode nor ActionScript. Microsoft just wanted to have control over every aspect of programming. They couldn't stand 3rd-party tools being that popular.

    And how much faster are bytecode languages from scripting languages? The only difference between them is the parser...
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  2. #17
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by maxorator View Post
    Microsoft just wanted to have control over every aspect of programming. They couldn't stand 3rd-party tools being that popular.
    Hoho, now who can argue with that?
    Microsoft wants to take over the world!
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #18
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    Did some 'pruning' in this thread to keep it on track.
    Last edited by VirtualAce; 05-17-2008 at 11:44 AM.

  4. #19
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Bubba does that mean most of your personal work is in D3D rather than OpenGL?

  5. #20
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    All of my 3D work is in Direct3D. I picked D3D and DX for many reasons but I won't get into that here lest we start a D3D/OGL war.

    I could pick up OGL easily enough since the 3D principles are exactly the same.

  6. #21
    Disrupting the universe Mad_guy's Avatar
    Join Date
    Jun 2005
    Posts
    258
    Quote Originally Posted by maxorator View Post
    On-the-fly means it's not compiled then. It simply means it is basically a processor emulator.
    First off, in the case of .NET, the language is still compiled because it is compiled to a binary, which runs on an abstract machine on which it will execute. That is what a compiler does. A compiler doesn't have to compile down to the raw assembly to be considered a compiler. It only has to go from source -> target.

    Second, it compiles the intermediate byte code into native code as it is executed. .NET and the JVM will do advanced optimizations on the bytecode you give it and covert it to native code, and for the rest of the time, execute that instead (in the case of .NET I believe the native code is actually stored inside the .exe after being run; when a method is invoked it has native code generated if it hasn't before. Java's HotSpot will do performance/profiling analysis as the program is running, and compile it to very highly optimized native code, then execute that.)

    I fail to see how this makes it not a compiler, of which the only definition is to transform a program from a source language into a target language. Now, our definitions of compiler may vary (which is totally fine, I might have missed your point some,) but I can't agree that it's a "processor emulator."

    And how much faster are bytecode languages from scripting languages? The only difference between them is the parser...
    What? No it isn't; the difference is in the actual execution of the source program. There is no difference in the parser. If you have a parser for Ruby, whether or not your backend generates bytecode for a VM or walks the AST and interprets it, the parser will return the same AST regardless; it's purely a backend implementation issue.

    As for a performance comparison, generally speaking virtual-machine based languages will execute faster than ones that purely generate an AST and then walk it; this is primarily because the virtual machine will be written to be fast and highly tuned to the language semantics, and the bytecode will be low level and tuned to the semantics as well.
    operating systems: mac os 10.6, debian 5.0, windows 7
    editor: back to emacs because it's more awesomer!!
    version control: git

    website: http://0xff.ath.cx/~as/

  7. #22
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    I would call the dotNet a dynamic compiler, as opposed to C/C++ and other languages which use a static compiler.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #23
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by Mad_guy View Post
    I fail to see how this makes it not a compiler, of which the only definition is to transform a program from a source language into a target language.
    No, a compiler transforms it from a programmign language to executable code. What you described is a translator, not a compiler. These have been around for awhile. Used to be all C++ code was translated into C code then compiled, until compiler could directly compile C++ code. BASIC also transforms its language into BYTECODE, so .NET is really just a glorified interpreter. Unless the bytecode is being sent directly to the processor as the instruction stream, its being interpreted. Interpreted languages are inhernetly slower even if there is a one to one relationship between the bytecode and the machine language. The bytecode must still be loaded by the interpreter and the equivelant machine instruction performed. This means that at most, and interpreted application will be half as fast as native code even with a perfectly optimized interpreter. I/O will generally be almost as fast for technical reason I wont go into here. Because computers are so fast, and becuase most .NET appications are heavily I/O bound (internet bandwidth limitations), the perceived speed difference will be negligeable.
    Last edited by abachler; 05-23-2008 at 09:48 AM.

  9. #24
    Disrupting the universe Mad_guy's Avatar
    Join Date
    Jun 2005
    Posts
    258
    No, a compiler transforms it from a programmign language to executable code. What you described is a translator, not a compiler.
    You do realize this is a circular definition, right? Compilers go from source -> target, end of story. Check wikipedia if you wish; check anywhere, the idea is all that matters and what you're talking about are useless details. Whether or not the target is actual assembly code, or the compiler has a backend to compile to another languages (many high level languages like chicken scheme will compile scheme to C) like C, it's still a - strictly speaking - a translation. Therefore, all compilers are inherently translators, and all 'programming language translators' are inherently compilers.

    You're doing nothing but nitpicking on words, and you haven't in any way made the definition I gave of a compiler false. How do the semantics and definition of this 'black box program' change, based on what the target output is? It's always going from source -> target, and there is nothing that strictly specifies the target must be machine code.

    Used to be all C++ code was translated into C code then compiled, until compiler could directly compile C++ code.
    Do you have something to back this up (honestly)? I've never heard of this approach, and I'm pretty skeptical unless you're just generalizing it a bit in which case I think I might get what you mean..

    Interpreted languages are inhernetly slower even if there is a one to one relationship between the bytecode and the machine language.
    Bringing up the speed of the approach completely misses the point I was trying to make - I was only pointing out that the JVM will take that java bytecode, and on the fly, compile it into adequate machine code. I never mentioned speed, although I might have said the word 'optimized.' It's irrelevant either way.

    This means that at most, and interpreted application will be half as fast as native code even with a perfectly optimized interpreter.
    Unfounded, useless statement.

    I/O will generally be almost as fast for technical reason I wont go into here. Because computers are so fast, and becuase most .NET appications are heavily I/O bound (internet bandwidth limitations), the perceived speed difference will be negligeable.
    This - again - is completely orthogonal and utterly irrelevant to the point I was making.
    Last edited by Mad_guy; 05-23-2008 at 03:31 PM.
    operating systems: mac os 10.6, debian 5.0, windows 7
    editor: back to emacs because it's more awesomer!!
    version control: git

    website: http://0xff.ath.cx/~as/

  10. #25
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Quote Originally Posted by Mad_guy View Post
    You do realize this is a circular definition, right? Compilers go from source -> target, end of story. Check wikipedia if you wish; check anywhere, the idea is all that matters and what you're talking about are useless details.
    Very well then. An image converter is a compiler then. And I'm sure you agree the details are useless.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  11. #26
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Do you have something to back this up (honestly)? I've never heard of this approach, and I'm pretty skeptical unless you're just generalizing it a bit in which case I think I might get what you mean..
    A certain fellow by the name of Bjarne Stroustrup, who might know something about how C++ was invented, makes a similiar claim.

    The same fellow calls his C++ to C translator "a traditional compiler", contradicting abachler's statement. Perhaps we could defend abachler's statement by pointing out that, at the end of the process, we still get machine code, much like how modern C++ compilers invoke an assembler. In other words, "source -> target" is too vague: we need to define what is the source, and what is the target.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  12. #27
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    I believe we can agree on some few general concepts that, while not aiming to encompass all scenarios, at least have the benefit of separating the waters. The last thing we need is to end this admiting against all that is natural, interpreted languages are the same as compiled languages.

    Their translation, compilation, linking and execution plans are completely different.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  13. #28
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by Stroustrup
    To build that, I first used C to write a "C with Classes"-to-C preprocessor. "C with Classes" was a C dialect that became the immediate ancestor to C++. That preprocessor translated "C with Classes" constructs (such as classes and constructors) into C. It was a traditional preprocessor that didn't understand all of the language, left most of the type checking for the C compiler to do, and translated individual constructs without complete knowledge.
    He calls its a preprocessor, and then goes on to say that it leaves the type checkign to the compiler, obviously making a distinction between the preprocessor which did the translating, and the compiler, implying that the preprocessor/translator is not a compiler.

    Quote Originally Posted by Mad_Guy
    I was only pointing out that the JVM will take that java bytecode, and on the fly, compile it into adequate machine code.
    Yes, this is called interpretting the code. Some distinction may be drawn if it only does this the first time the application is run, but last I checked JVM does this every single time, otherwise it would be the Java Runtime Engine or somethign similar and would completely defeat one of the purposes of using a virtual machine, and that is to prevent malicious code from having direct access to the execution stream.

    Im not saying Java is bad because its interpretted, this is in fact one of its strengths, but that still doesnt make it compiled code. I personally dont use java becuase it is ill suited to my applications, but for applications that are heavily I/O bound, there may be little point in optimizing execution speed. Again, this doesnt make JVM just as fast as say C/C++, it just mitigates the effect of that weakness in teh final analysis.
    Last edited by abachler; 05-24-2008 at 09:34 AM.

  14. #29
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    He calls its a preprocessor, and then goes on to say that it leaves the type checkign to the compiler, obviously making a distinction between the preprocessor which did the translating, and the compiler, implying that the preprocessor/translator is not a compiler.
    I think you misread. The "preprocessor" refers to "C with Classes"-to-C, and this was used to write Cfront. Cfront itself was what he called a "a traditional compiler", and this compiled C++ to C.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  15. #30
    Disrupting the universe Mad_guy's Avatar
    Join Date
    Jun 2005
    Posts
    258
    Quote Originally Posted by Mario F. View Post
    Very well then. An image converter is a compiler then. And I'm sure you agree the details are useless.
    Taken out of context? Sure.

    Im not saying Java is bad because its interpretted, this is in fact one of its strengths, but that still doesnt make it compiled code.
    Whoa, look, the last thing I was talking about was the word translation vs. the word compiler; have I missed something here, or did we just skip a beat? In any case, it is arguable whether the approach taken by the JVM is a traditional 'compilation' strategy (which I would classify as 'yes,' still) or not (the fence you're on,) and that is just left up to the interpretation of the reader. It's arguable what qualifies as 'compiled code.' I think it's best to leave it at that. On the note of compiler vs. translator, I find on the note of any ambiguity or any noticable difference, there is none and it's a clear-cut issue.

    We're shifting points though - the statement of mine you're quoting is in a response to a useless statement you made earlier when we were on the topic of 'what's a compiler,' only clarifying what my point was and how speed wasn't it and nothing about I/O-bounds and all this, and now we've moved onto what's compiled code and strengths, weaknesses and other stuff: if we're going to try and make a point then we need to stay on topic, because it's getting tough to try and remember what the original topic even was.
    operating systems: mac os 10.6, debian 5.0, windows 7
    editor: back to emacs because it's more awesomer!!
    version control: git

    website: http://0xff.ath.cx/~as/

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Another syntax error
    By caldeira in forum C Programming
    Replies: 31
    Last Post: 09-05-2008, 01:01 AM
  2. Quantum Random Bit Generator
    By shawnt in forum C++ Programming
    Replies: 62
    Last Post: 06-18-2008, 10:17 AM
  3. Puzzled.
    By silhoutte75 in forum C Programming
    Replies: 13
    Last Post: 01-21-2008, 05:17 PM
  4. Request for comments
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 15
    Last Post: 01-02-2004, 10:33 AM