Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Thief^]

Hand-optimised assembly can be faster, but it's only by a minor amount normally. This is why in professional game development C++ is used for most things. Hand-assembly was often used for things which needed that minor speed boost or strange instructions (like SIMD), but compiler intrinsics have mostly replaced the latter.

EDIT: Unlike vs Java and other languages, where there is an order-of-magnitude speed difference...

[Cyntrox]

There's also the development time to consider...

If DF was written in assembly, it probably wouldn't be playable at all yet. Writing c++, on the other hand, isn't a lot slower than writing java.

[hermes]

Forget all that noise - what I want to know is how long it takes for a fresh build to compile.

I think I recall Toady saying "20 minutes" or something a year ago, perhaps.  Or was it an hour?  I'm not sure and wouldn't be able to find a link.  Sorry, not really helpful

[devek]

Hand-optimised assembly can be faster, but it's only by a minor amount normally. This is why in professional game development C++ is used for most things. Hand-assembly was often used for things which needed that minor speed boost or strange instructions (like SIMD), but compiler intrinsics have mostly replaced the latter.

EDIT: Unlike vs Java and other languages, where there is an order-of-magnitude speed difference...

Order of magnitude? Really? So you think DF written in Java would cruise at 5 fps in situations the C++ version would go 50 fps? I would like to see one benchmark where Java was an order-of-magnitude slower for anything. In the real world, the languages run on par. This is confirmed by anyone who actually good at both of them and by plenty of benchmarks that can be found with a simple google search. I can see how average people would be confused, just repeating what what they hear in chat rooms and such but...

What really boggles my mind is the thought that assembly is just a small improvement? In situations where cycles matter, such as embedded or nuclear/scientific calculations people use assembly for huge gains. You write an assembly program totally different, there is no equivalent to what you are doing in c based languages.

Professional game developers usually license an engine(that usually has a codebase that predates java). To assume the guts of those engines is not in assembly is absurd. It is hard to tell because the current code behind those engines is not open. Still, the source for engines id software has open sourced are full of assembly and those couldn't be ported to Java or C without a huge performance loss.

You could write an engine from scratch. It would suck compared to what is out there, but lets ignore that. If you were starting from scratch, you might as well use Java with opengl bindings. You would finish the project faster and get free portability. The left-over time could be used to profile the code to run faster than the c++ version that just squeaked out the door. It happens all the time in the business world....

There's also the development time to consider...

If DF was written in assembly, it probably wouldn't be playable at all yet. Writing c++, on the other hand, isn't a lot slower than writing java.

Are you sure about that? DF did start in 2002.

[MaDeR Levap]

In the real world, the languages run on par. This is confirmed by anyone who actually good at both of them and by plenty of benchmarks that can be found with a simple google search.

I do not give a crap about benchmarks. Most of them are profiled or just plain biased to show what programmer want. Java do a++; zilion times over in same time as c++? Very menanigful and revelant to real life, really.

I programmed in C++ and I currently work with Java. Java is slower than C/C++. This is fact. Get over it.

To assume the guts of those engines is not in assembly is absurd.

Someone would start wonder why not entire engine is in assembly, only most critical parts. Wait, you below propose similiar thing...

If you were starting from scratch, you might as well use Java with opengl bindings. You would finish the project faster and get free portability. The left-over time could be used to profile the code to run faster than the c++ version that just squeaked out the door.

Someone would thought that fair comparison of mature java+bingings (do you mean Ogre, JOGL and similiar?) engine would be ""mature c++ version" of said engine, not "just squeaked out the door". Anyway, I agree that Java version would not be "orders of magnitude slower", just a little slower. Well, maybe Thief^ had on mind doing everything purely in Java, then sure. 

If DF was written in assembly, it probably wouldn't be playable at all yet. Writing c++, on the other hand, isn't a lot slower than writing java.

Are you sure about that? DF did start in 2002.

I am fairly sure that Toady begun development in C and later moved to C++. And what, do you deny that programming in assembly would be very slow?

[ZCM]

Are you kidding? I rarely see compilers bust out SIMD and some of the shitty ones (like MSVC) don't even make sense. The argument doesn't follow. You can't say that a c compiler will beat a bad programmer. By that logic, Java blows away C because it can implement a hash better than a bad C coder.

I've still yet to see any compiler make a functional program in less than 1000 bytes. If I wrote dwarf foreman in assembly it would be like 10k, and I would love to see any C program touch it for speed.

Keep telling yourself that. There's a reason John Carmack gave up writing hand-tuned assembler. Modern processors are too complicated, and working out the optimal instruction order given pipelining is a job for a computer.

I programmed in C++ and I currently work with Java. Java is slower than C/C++. This is fact. Get over it.

I can't testify about Java, but I write C# for a living. I had some code that was very, very slow, but after some careful profiling and rewriting with performance in mind, it was comparable or even better than code written in c++ by a performance expert. (Hint: Allocating memory in your inner loop is bad, no matter what language you're using.)

[Astramancer]

(Hint: Allocating memory in your inner loop is bad, no matter what language you're using.)

Ouch.

It is amazing how much code you can snip out just by going through a completed program again, and most of those tweaks usually make it run noticeably faster, too.

[Normandy]

[snip]

I've still yet to see any compiler make a functional program in less than 1000 bytes. If I wrote dwarf foreman in assembly it would be like 10k, and I would love to see any C program touch it for speed.

This second part is just plain disingenuous. Memory is cheap. The fact that a compiler can't make a program under 1 kB is pretty moot.

It might also be worth it to point out that some of Java's "slowness" comes from the JNI - attempting to make a call to native code, say to use the graphics card or call some "optimized" assembly code, has quite some overhead.

[Veroule]

Allocating memory can be a big speed killer.  Even in a single threaded application the memory manager has to do thread locking for its private tables, then search for an appropiately sized chunk, set its internal data marking that chunk used, then return the proper pointer.  Resizing may or may not require copying all of the data depending on the original request and the size of the chunk that was provided.  Generally a resizing call can check the chunk to see if it meets sizing requirements before any the above allocation routine has to take place, which occasionally avoids the clock cycle minimum for thread locking.

Doing anything in a loop that can be done outside the loop is bad.  It doesn't matter that it willl only amount to a single instruction, taking 1 clock cycle, when that loop runs 4000 times each time it is traversed; and the loop gets traversed 1000 times by a single higher function call.

I've still yet to see any compiler make a functional program in less than 1000 bytes.

You just aren't old enough.  Current compilers will take over 1k to produce the simple "Hello world" example because they use the PE header format.  If I dug out an old compiler that produced stuff in a COM format then it would be under 1k.  If goes a step or 3 further and pull out the really ancient bookss of BIOS interupt calls then I can get it under 50 bytes, and that would still be done by an old compiler producing a COM file.

[Kholint]

Incidentally, if you're wondering whether it'd be *possible* to write DF in assembly (regardless of any performance advantages it may bring), note that RollerCoaster Tycoon (http://en.wikipedia.org/wiki/RollerCoaster_Tycoon) was written 99% in assembly, with some C bindings to let the game interface with Windows.

Given that it's a sandbox game that gives the player considerable freedom to build and experiment just like DF, that's... incredible.

[ZCM]

You just aren't old enough.  Current compilers will take over 1k to produce the simple "Hello world" example because they use the PE header format.  If I dug out an old compiler that produced stuff in a COM format then it would be under 1k.  If goes a step or 3 further and pull out the really ancient bookss of BIOS interupt calls then I can get it under 50 bytes, and that would still be done by an old compiler producing a COM file.

Fortunately, stuff in the header doesn't have any real performance impact; the overhead of reading it from disk is going to be swamped by all the other stuff that goes into starting a program. The size of the code for a hot path can matter, but only if it exceeds your CPU's I-cache size.

This discussion is overlooking one major aspect of performance, though: programmer performance. Coding in a higher-level language like C# or Java can eliminate days of trying to track down obscure bugs and unreproducible crashes, time that you can spend adding actual features. They also encourage a programming style that makes it easier to experiment with different data structures and algorithms, which can give a much greater speedup than local optimizations ever will.

[Normandy]

Haha, obscure bugs. You know what's so cool?

Spoiler (click to show/hide)

Code: [Select]

#include <iostream>

class Object
{
public:
    void print() { std::cout << "Hello World!"; }
};

int main()
{
    Object *obj = NULL;
    obj->print();
}

Try it out. This only throws a run-time error if print() is virtual. -Wall says nothing. Imagine my surprise when I learned that. ZCM is more than right about programmer performance.

[Nilik]

Incidentally, if you're wondering whether it'd be *possible* to write DF in assembly (regardless of any performance advantages it may bring), note that RollerCoaster Tycoon (http://en.wikipedia.org/wiki/RollerCoaster_Tycoon) was written 99% in assembly, with some C bindings to let the game interface with Windows.

Given that it's a sandbox game that gives the player considerable freedom to build and experiment just like DF, that's... incredible.

Wasn't it also written pretty much entirely by one guy, Chris Sawyer?

ITT: Nerd fight!

[claer_runway]

i remember roller coaster tycoon. it ran perfectly on my POS windows 95 machine. it was amazing.

[Veroule]

Haha, obscure bugs. You know what's so cool?

That isn't quite so obscure, you just have to understand how virtual tables are built by the compiler.  What you have now never referencesthe pointer that is null.  When you set the print function to virtual then the compiler does a few other things.  Here is what it would look like in C as a virtual:

Spoiler (click to show/hide)

Code: [Select]

#include <iostream.h>
typedef struct {
 int Type; //added by compiler for virtual
} Object;
//C conversion of class method
void print0(Object* this) {fprint(cout, "Hello World!"); } //renamed by compiler for virtual
void print(void* this) { //added by compiler for virtual
 switch (this->Type) {
  case 0: print0(this);break;
 }
}

int main() {
 Object *obj = NULL;
 print(obj);
}

As you can see the compiler adds a few things for you to handle the virtual, and among those is a blind read through the pointer.  You should always have some idea of how the underlying code being added by compiler looks.  It doesn't necessarily help you find a crash, but can sometimes help you pick when it is  a good usage of time to write your own lower level object.

This discussion is overlooking one major aspect of performance, though: programmer performance. Coding in a higher-level language like C# or Java can eliminate days of trying to track down obscure bugs and unreproducible crashes, time that you can spend adding actual features. They also encourage a programming style that makes it easier to experiment with different data structures and algorithms, which can give a much greater speedup than local optimizations ever will.

Very true.  It is one of those triangle concepts, there are 3 different factors that can be done on the project, but you can only pick 2 at a time.  Programming generally has the 3 factors of memory usage, run time speed, writing speed.