Post-1.6.0 performance

[duds26]

Thanks for answering, is this stuff a part of the C/C++ standard?

[selden]

I'm not sure which "stuff" you mean.

The C and C++ standards define the type of text you can put into the source code files.

The ways you invoke a compiler and tell it what to do with the souce code, and the types of binary codes that a compiler emits are unique to each compiler.

[t00fri]

...
The C and C++ standards define the type of text you can put into the source code files.

The ways you invoke a compiler and tell it what to do with the souce code, and the types of binary codes that a compiler emits are unique to each compiler.

??

Fridger

[duds26]

With stuff I meant the possibility, function to declare an architecture/instruction set and write architecture/instruction set specific instructions in the body.
(The architecture/instruction set specific instructions will obviously not be part of the standard.)

[selden]

With stuff I meant the possibility, function to declare an architecture/instruction set and write architecture/instruction set specific instructions in the body.
(The architecture/instruction set specific instructions will obviously not be part of the standard.)

The C and C++ language standards really don't specify anything about any particular architecture. The standards specify the contents of the source files -- what you have to write so numbers get added together, for example,

Code: Select all

c = a + b;

or what you write to invoke a mathematical function

Code: Select all

x = tan(theta);

The language standards specify some of the features that compilers must support (like the ability to call a subroutine), but not the details of how it is to be implemented in binary machine code. Each compiler vendor also adds their own special features to their compilers.

Most compilers are designed to run on a single architecture and generate code only for that architecture Some compilers (like the GNU compilers) are designed to be able to run on one architecture and generate code for some other architecture. This is called "cross compiling". The way you declare the architecture and instruction set to be used is unique to each compiler product. Gnu compilers do it one way. Commercial compilers usually have their own different techniques.

Some compilers, including the GNU compilers, make it possible to include architecture-specific assembly langage instructions in the middle of the C or C++ source code. This is not part of the language standards. Sometimes using assembly language is necessary when the code generated by the compiler isn't very good, but it's generally a very bad thing to do, since the resulting program can only run on one particular architecture.

[duds26]

...but not the details of how it is to be implemented in binary machine code."
That's fine and not what I asked.
My question about the standard would be able to define a place to put those instructions in and something to say: it's for this architecture

IF(this architecture){
<block of binary code>
}

(If nothing in else then there would stand an else with a empty body.)

Some compilers, including the GNU compilers, make it possible to include architecture-specific assembly langage instructions in the middle of the C or C++ source code. This is not part of the language standards. Sometimes using assembly language is necessary when the code generated by the compiler isn't very good, but it's generally a very bad thing to do, since the resulting program can only run on one particular architecture.

Being able to do an if(instruction set/architecture{<block of binary code/assembly language>}else{<source code>} construction would be handy.
The standard allowing to specify the name is enough for me. The details even don't have to be said because the compiler would just put the block of binary code in place without compiling if it's the same architecture. Else it would compile the source code in the else tag.

[selden]

Embedding hand-written architecture-specific code almost invariably turns out to be a very bad idea. Every compiler does it differently, and it is a maintenance nightmare.

Sometimes it can be justified when a program is written only for a specific architecture, will not be needing many changes, will only be compiled using a particular compiler, and there is no other way to meet the requirements of the project. None of these are the case for Celestia: it is written to run on many architectures, is constantly being changed and improved (although slowly), must be compilable by many different compilers, and there are invariably other ways to meet Celestia's requirements.

[duds26]

It is indeed a very bad idea and should be avoided.
Always, even if the conditions are generous.
(If you need to have something compiling can't provide, then it's worth doing something.)
Happy to see that Celestia will stay universal.

[selden]

Yesterday I replaced my 5 year old Pentium 4 tower computer with a modern core i7 laptop. The old system's motherboard had died.

New system specs:
8GB, 1.6GHz Core i7 Q720; Win 7 Pro 64bit
Nvidia NVS 3100M; ForceWare v189.74, OpenGL 3.1
display: 1920x1080.

I benchmarked it using the URLs Chris provided in the first post of this thread:

Celestia versions
1.6.0 | r5038
-------------
1 170 | 210
2 76 | 91
3 290 | 290
4 102 | 108
5 256 | 295

I ran Celestia in a maximum-sized desktop window, not in full screen mode.
The new system seems to be performing roughly half-way between my old system and what Chris has.

I built r5038 under Win 7 using VS 2008 sp1. Using the "Web install" procedure it automatically installed the right SDK without having to do it manually.

FWIW, after reading other people's reports of problems with Vista and Win7, I decided not to even try to install Celestia in Program Files. I created the directory C:\MyPrograms and installed Celestia v1.6.0 there instead (along with some other packages like MMPS and Anim8or). It runs with no problems whatsoever.

[duds26]

Using Windows Vista Home Premium 32bit
Have Celestia installed in Program Files and it works fine there.