Archived

This topic is now archived and is closed to further replies.

Spearhawk

C file IO faster than C++ file IO?

Recommended Posts

Hi, I decided to re-write the OGL for Game Programming''s tga loader with C++ style file reading instead of C style. Only now my egine takes about twice as long to load. Is C++ file IO slower, or did I do someitng wrong? The code for the loading function is below (old C style commented out). Thanks in advance
  

bool GcTarga::Load(char *fileName)
{
	//byte		ucharBad;		// Garbage byte data

	//short int	sintBad;		// Garbage short int data

	long		imageSize;		// Since of TGA image

	int			colorMode;		// 4 for RGBA or 3 for RGB

	byte		colorSwap;		// Swap variable


	// Open the TGA file

	//filePtr = fopen(fileName, "rb");

	ifstream file(fileName, ios::in | ios::binary);

	// Check to see if opened

	if(!file) {
		MessageBox(NULL, "Failed to open TGA file.", "ERROR", MB_OK);
		return false;
	}

	// Read first two bytes of data not needed

	file.seekg(sizeof(byte) * 2, ios::cur);
	//file.read((char*)&ucharBad, sizeof(byte));

	//file.read((char*)&ucharBad, sizeof(byte));


	// Read the image type

	//fread(&imageTypeCode, sizeof(byte), 1, filePtr);

	file.read((char*)&imageTypeCode, sizeof(byte));

	
	// Check that it''s the corect type

	if((imageTypeCode != 2) && (imageTypeCode != 3)) {
		fclose(filePtr);
		MessageBox(NULL, "The TGA file is not of a suported format", "ERROR", MB_OK);
		return false;
	}

	// Skip unneaded data

	//fread(&sintBad, sizeof(short int), 1, filePtr);

	//fread(&sintBad, sizeof(short int), 1, filePtr);

	//fread(&ucharBad, sizeof(byte), 1, filePtr);

	//fread(&sintBad, sizeof(short int), 1, filePtr);

	//fread(&sintBad, sizeof(short int), 1, filePtr);

	file.seekg(sizeof(short int) * 4 + sizeof(byte), ios::cur);

	// Read image dimensions

	//fread(&imageWidth, sizeof(short int), 1, filePtr);

	//fread(&imageHeight, sizeof(short int), 1, filePtr);

	file.read((char*)&imageWidth, sizeof(short int));
	file.read((char*)&imageHeight, sizeof(short int));
	
	// Read bit depth

	//fread(&bitCount, sizeof(byte), 1, filePtr);

	file.read((char*)&bitCount, sizeof(byte));

	// Read 1 byte of garbage data

	//fread(&ucharBad, sizeof(byte), 1, filePtr);

	file.seekg(sizeof(byte), ios::cur);

	// Check for depth

	if((bitCount == 24) || (bitCount == 32))
	{
		// colorMode -> 3 = BGR, 4 = BGRA

		colorMode = bitCount / 8;
		imageSize = imageWidth * imageHeight * colorMode;

		// Allocate memory for image data

		imageData = (byte*)malloc(sizeof(byte) * imageSize);

		// Read image data

		//fread(imageData, sizeof(byte), imageSize, filePtr);

		file.read((char*)imageData, sizeof(byte) * imageSize);

		// Change BGR to RGB (BGRA to RGBA)

		for(int i = 0; i < imageSize; i += colorMode)
		{
			colorSwap = imageData[i];
			imageData[i] = imageData[i + 2];
			imageData[i + 2] = colorSwap;
		}
	}
	else if(bitCount == 16)
	{
		unsigned short pixels = 0;
		int r=0, g=0, b=0;

		// RGB color mode (after conversion)

		colorMode = 3;
		imageSize = imageWidth * imageHeight * colorMode;

		// Allocate memory for image data

		imageData = (byte*)malloc(sizeof(byte) * imageSize);

		// Load in all the pixel data pixel by pixel and convert to RGB

		for(int i = 0; i < imageWidth * imageHeight; i++)
		{
			// Read in the current pixel

			//fread(&pixels, sizeof(unsigned short), 1, filePtr);

			file.read((char*)&pixels, sizeof(unsigned short));
			
			// Change the pixel to 24 bit

			b = (pixels & 0x1f) << 3;
			g = ((pixels >> 5) & 0x1f) << 3;
			r = ((pixels >> 10) & 0x1f) << 3;
			
			// Swap to RGB and save in array

			imageData[i * 3 + 0] = r;
			imageData[i * 3 + 1] = g;
			imageData[i * 3 + 2] = b;
		}
	}
	else
	{
		MessageBox(NULL, "TGA file of a not suported bpp", "Error", MB_OK);
		return false;
	}

	// Close the file

	file.close();
	//fclose(filePtr);


	return true;
}  
-- Spearhawk productions Project Andromeda

Share this post


Link to post
Share on other sites
were you benchmarking debug or release build?

iostreams sit on top of stdio, so they will be slightly slower than using stdio if all you need is stdio-style read and write functions. then again, you can use low-level i/o functions in <io.h> and avoid stdio buffering if you know that your operating system will buffer and/or cache data for you (win32 does, dos doesn''t).

of course, your code can be optimized on algorithm level (as usual). use one read call to read in the entire header, and use one read call per line of image data, not for every pixel. you''re killing performance by constantly invoking i/o functions when you should read a sizable block of data at once, process it, then repeat.

Share this post


Link to post
Share on other sites
quote:
Original post by YodaTheCoda
u silly poppet u shud not use a exclimaton mark on a ifstream thing cos its not a pointer. use ifstream::is_open insted.

Acording to "C++: The Complete Refernce" if(!file)... is a valid way to check if the file was opened or not. Of course, considering Schikdt's reputation it might be wrong...


Thanks niyaw. I was using debug mode for the testing, I know that it's not optimed but since both was in debug mode they should suffer as much, shouldn't they? I have now tested in release mode and the diffrence is still there, although both goes a bit faster.
Anyway, I guess I'll just re-write it as per your sugiestions, just thought it a bit odd that while I was doing the same thing in C and C++ style the C style was much faster.


--
Spearhawk productions
Project Andromeda


[edited by - Spearhawk on March 4, 2003 9:32:09 PM]

[edited by - Spearhawk on March 4, 2003 9:32:37 PM]

Share this post


Link to post
Share on other sites
No, it''s not a pointer; it''s an object. Therefore, it can have overloaded operators. In this case, the ! operator returns fail(), meaning it can be used to determine if the operation completed successfully.

Share this post


Link to post
Share on other sites
quote:
Original post by YodaTheCoda
[quote]if(!file)

u silly poppet u shud not use a exclimaton mark on a ifstream thing cos its not a pointer. use ifstream::is_open insted.

Uhm... ohkayyyyyy

I see you must have your PhD in CompSci.



Share this post


Link to post
Share on other sites
Yes, C functions happen to be faster than their C++ counterparts in most cases you''ll find, because most C++ implementations simply call the C counterpart, meaning it''s just extra over-head. If you use block reading, this difference will be small, because less calling overhead, and you''ll start getting closer to the maximum transfer rate of your hard-drive, so instead of being memory/cpu limited by having so much over-head, it will be hardware limited, meaning either way will be about as fast, since both are waiting on the hard-drive. That said, I normally use C functions to do everything, since they are normally faster. I have been using classes a lot more lately due to their ease of use (constructors, destructors, inheritance, etc), but in my raytracer, I found that putting everything in classes resulted in a HUGE drop in performance, and these were SIMPLE classes. (It was along the lines of a 400% increase when switched to straight C structs from classes). I found it very odd that classes were so slow (yes, it was tested in release mode), I always thought that they were much more efficient (and please, don''t tell me I was using them incorrectly, etc, etc, because they were VERY simple classes, constructor, destructor, some member functions that dealt with the creating/modifying/etc of the class, and the member variables... no over loaded functions, no virtual functions, etc. All I did when switching to structs, was pulled all the functions out of them, and made the functions take a struct of that type, and this resulted in a 400% increase in rendering speed on average!).

Share this post


Link to post
Share on other sites
Ready4Dis: "I found it very odd that classes were so slow (yes, it was tested in release mode), I always thought that they were much more efficient (...)"

Nope, slower, for the very reason you give: C++ classes are basically an overlay of C, so you get the penalty of the extra level of abstraction.

Same reason the display core of most games'' engines used to be written in assembly, rather than C, even though C was used for the outer game shell and logic -- well written ASM can much faster than C, because it''s one abstraction layer closer to the machine.

The "efficiency" of classes that you mentioned is really programmer efficiency: once you''re used to inheritance, polymorphism, etc, you have another tool in your toolchest. A powerful one. You can simulate all those things in C. It''s just not clean or pretty. In C++, though, it can "look" clean, and is easier to do code reviews of.

Use a code profiler, see what parts of your code are taking most of the CPU. Drop those down to C. If already there, drop further. You can still get all the benefits of OO design and have fast code, you just need to write certain functions at a lower level.

Share this post


Link to post
Share on other sites
quote:
Original post by Spearhawk
I was using debug mode for the testing, I know that it''s not optimed but since both was in debug mode they should suffer as much, shouldn''t they?


The less data you read in a single request, the more time proportionally it takes to make function calls, validate arguments, update file pointers, etc. than it takes to actually move the data from harddrive and/or disk cache to your application. Increasing number of bytes read per call will mitigate the performance hit incurred by high-level i/o code (iostream-stdio-low-level io, if you''re talking win32 api). in particular, debug builds usually have disabled optimizations and inline functions, on which stl relies to get fast execution. make sure your release build is optimized before you run tests. and do read more than one byte per call.
quote:

Anyway, I guess I''ll just re-write it as per your sugiestions, just thought it a bit odd that while I was doing the same thing in C and C++ style the C style was much faster.


if you''re looking for something really fast, use a file mapping. this will give you data directly from the operating system disk cache, eliminating many intermediate code layers and unnecessary buffer copies.

Share this post


Link to post
Share on other sites
quote:
Original post by Merle
Nope, slower, for the very reason you give: C++ classes are basically an overlay of C, so you get the penalty of the extra level of abstraction.


what exactly constitutes this "penalty" you're talking about?
quote:

Same reason the display core of most games' engines used to be written in assembly, rather than C, even though C was used for the outer game shell and logic -- well written ASM can much faster than C, because it's one abstraction layer closer to the machine.


code that writes to video memory might still be written in assembly, utilizing latest processor technologies such as sse. are you implying that the same techniques can be used with equal success for high-level tasks like file i/o?
quote:

The "efficiency" of classes that you mentioned is really programmer efficiency...


interesting. do you think you can do better than compiler at implementing virtual functions, multiple inheritance, templates, and so on? compare apples to apples. using classes vs not using classes is a non-argument; try classes vs code that achieves equivalent result without using classes.
quote:

Use a code profiler, see what parts of your code are taking most of the CPU. Drop those down to C. If already there, drop further. You can still get all the benefits of OO design and have fast code, you just need to write certain functions at a lower level.

algorithm-level optimizations have far more noticeable impact on overall code performance than assembly-level optimizations. in the current scenario, reading entire file header with a single iostreams' read() call will be faster than any assembly you can write that reads by one, two or four bytes at a time. time spent moving c++ code into assembly is better spent writing better c++ code, if not for this task, then for something else.

[edited by - niyaw on March 4, 2003 11:18:10 PM]

Share this post


Link to post
Share on other sites
We''ve already solved the problem! Read the files all at once (or in large chunks) into memory, and then work with them.

As for C++ vs C (not again?!), I''ve just got a few comments. First, though it is quite possible to write slow code in C++ (and it might even be easier than in C), there is nothing about objects that makes them inherently slower than their C-style equivalents. In many cases they compile to the same thing. In this particular instance, the issue isn''t so much C vs. C++; it''s the C++ standard library versus the old C standard library. Since C++ iostreams wrap C stdio, they may be a little slower, but they certainly read in large blocks of data at the same speed even if the function calls themselves are a bit slower, so it shouldn''t matter, since you should be reading large chunks at a time anyway.


  
//Open file

ifstream fileIn("C:\\stuff\\xyz.txt", ios::binary | ios::in);

//Get length of fileIn

fileIn.seekg(0,ios::end);
long length = fileIn.tellg();
fileIn.seekg(0, ios::beg);

//Load file

char * fileArry = new char[length];
fileIn.read(fileArry, length);

//Close file

fileIn.close();

//Do stuff with loaded file (fileArry)


//Clean up

delete [] fileArry;

Share this post


Link to post
Share on other sites
Me: "Nope, slower, for the very reason you give: C++ classes are basically an overlay of C, so you get the penalty of the extra level of abstraction."
niyaw: "what exactly constitutes this "penalty" you''re talking about?"

Pretty much all the OO stuff. Any time you need to use virtual functions, runtime type checking, etc, it''s adding a layer of slowness.

I''m sorry if it sounded like a C vs C++ tirade I was starting. I''m not claiming one is better than the other; more that for certain things (like file I/O) I think C is a better choice. Just not having to create the ifstream should be a bonus...


Me: "The "efficiency" of classes that you mentioned is really programmer efficiency..."
niyaw: "interesting. do you think you can do better than compiler at implementing virtual functions, multiple inheritance, templates, and so on?"

Certainly not!

It''s more that I''m saying that OO languages are giving you those abstractions invisibly, so you don''t have to kludge them yourself. As such, you are sometimes going to incur penalties (like RTTC).

When coding in an OO language, it''s easy to slip into the though that everything that can be OO, should be. Sometimes whole class hierarchies are created when it would have been sufficient just to pass a struct around. But this is better addressed by your statement:

niyaw: "algorithm-level optimizations have far more noticeable impact on overall code performance than assembly-level optimizations."

Share this post


Link to post
Share on other sites

TerranFury was right, read the file in one go. But then don''t have to read the whole file at once (in case the file is huge and not a valid file), just read the 18-byte header will do. If all verified, then only you read the rest of the TGA data.

Why? Because access to secondary storage is always slower, reduce the number of file read is the key.

Share this post


Link to post
Share on other sites
C is faster. C++ was originally written as a preprocessor to C. C++ code was compiled into C code which was then compiled into machine code. While that''s not how compilers work nowadays, the method isn''t that far off. Another thing is that C compilers have become very evolved over the years, and do an excellent job of optimizing your code for you. Certainly, I use C++ for a lot of things, but whenever i can use C without killing the readability, i do. Why bother with classes when the C code can be just as readable, and more efficient? Most of the popular games you play don''t use C++. Read this question on a programming test used by ea games:

Write an optimized C program to convert a base 16 number to its base 10 equivalent, without using the standard C libraries, i.e. don’t use scanf(“%x”). The program should allow the user to input the number. State any assumptions you made when writing the program. Use 23DA as a test number.

Do you think they''re interested in your C++ skills? They consider scanf() too slow. C++ is a wonderful language, but it''s made for programs that can afford to waste some clock cycles here and there. That includes almost every program written, with the exception of the graphics industry. The game industry is one of the few fields of CS where code optimization is still a priority.

Share this post


Link to post
Share on other sites
JFC, the reason the iostream classes are slower, is due to the additional buffering they perform for stream manipulation.

The stdio functions are part of C++ so it's not slower than C.
Many aspects of C++ are faster than C (inlining, functors, and template). However the streaming classes are for convenience and safety sake, not performance.

- Magmai Kai Holmlor

"Oh, like you've never written buggy code" - Lee

[Look for information | GDNet Start Here | GDNet Search Tool | GDNet FAQ | MSDN RTF[L] | SGI STL Docs | STFW | Asking Smart Questions ]

[Free C++ Libraries | Boost | ACE | Loki | MTL | Blitz++ | wxWindows| Spirit(xBNF)]
[Free C Libraries | zlib ]



[edited by - Magmai Kai Holmlor on March 5, 2003 11:40:19 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by kdogg
C is faster. C++ was originally written as a preprocessor to C. C++ code was compiled into C code which was then compiled into machine code. While that''s not how compilers work nowadays, the method isn''t that far off. Another thing is that C compilers have become very evolved over the years, and do an excellent job of optimizing your code for you. Certainly, I use C++ for a lot of things, but whenever i can use C without killing the readability, i do. Why bother with classes when the C code can be just as readable, and more efficient? Most of the popular games you play don''t use C++. Read this question on a programming test used by ea games:

Write an optimized C program to convert a base 16 number to its base 10 equivalent, without using the standard C libraries, i.e. don’t use scanf(“%x”). The program should allow the user to input the number. State any assumptions you made when writing the program. Use 23DA as a test number.

Do you think they''re interested in your C++ skills? They consider scanf() too slow. C++ is a wonderful language, but it''s made for programs that can afford to waste some clock cycles here and there. That includes almost every program written, with the exception of the graphics industry. The game industry is one of the few fields of CS where code optimization is still a priority.



Where to begin. C is NOT faster than C++.

Next, it''s not that they consider scanf too slow. They want to see if you understand how numbers work. I don''t actually understand the purpose of that question anyway. All numbers are really stored in base 2. I don''t understand what you are converting to/from. Do they mean input and output to the user, because in a C program it won''t matter at all.

Anyway, the important part is that C++ is not slower than C.

Share this post


Link to post
Share on other sites
okay, mr. wise guy.
quote:
Original post by kdogg
C is faster.


than what? c++? most c is valid c++, and thanks to inlining, moving from c to c++ can give you a performance increase. and unless you have a good c compiler and a crappy c++ one, your performance won''t decrease.
quote:

C++ was originally written as a preprocessor to C.


since this isn''t a widely used application of c++, why does it matter?
quote:

C++ code was compiled into C code which was then compiled into machine code. While that''s not how compilers work nowadays, the method isn''t that far off.


both c and c++ will be compiled assembly/machine code if your compiler is any good. now, how far is this from what exactly?
quote:

Another thing is that C compilers have become very evolved over the years, and do an excellent job of optimizing your code for you.


oh, really? well, here''s a surprise for you: c++ compilers have become very evolved over the years, and do an excellent job of optimizing your code for you.
quote:

Certainly, I use C++ for a lot of things, but whenever i can use C without killing the readability, i do.


which is in what way better than using c++ for everything? what''s the point that you''re trying to make here? c++ is evil and should be used when nothing else works?
quote:

Why bother with classes when the C code can be just as readable, and more efficient?


and why bother with c code when classes can be just as readable, and more efficient?
quote:

Most of the popular games you play don''t use C++.


and some do. in any case, how is this relevant to someone who is learning? people who have a dozen years of experience writing c code will naturally be able to code in c better than in c++. this doesn''t mean that people who have experience with c++ will code in c better than in c++, does it?
quote:

Read this question on a programming test used by ea games:

Write an optimized C program to convert a base 16 number to its base 10 equivalent, without using the standard C libraries, i.e. don’t use scanf(“%x”). The program should allow the user to input the number. State any assumptions you made when writing the program. Use 23DA as a test number.

Do you think they''re interested in your C++ skills? They consider scanf() too slow.


Cold_Steel already corrected your misconception here.
quote:

C++ is a wonderful language, but it''s made for programs that can afford to waste some clock cycles here and there.


which would include, for instance, unreal tournament? and c wasn''t made for programs that can afford to waste some clock cycles here and there? i bet stroustrup sat down and said "here''s the wonderful c language, how can we make it waste some clock cycles here and there so that it perfectly suits programs that do just that?" get some sense already.
quote:

That includes almost every program written, with the exception of the graphics industry.


this just shows that you have no clue what you''re talking about.
quote:

The game industry is one of the few fields of CS where code optimization is still a priority.

and what are all other fields where code optimization is not a priority? maybe database applications? or web applications? or data mining applications? or image processing applications? how about operating system kernels?

i suggest you refrain from posting such crap in future until you realize the following things:
1. using c instead of c++ does not make you a good programmer.
corollary: using c instead of c++ does not make your code more efficient. if it does, you suck at c++.
2. don''t use examples that were not intended to illustrate your points.
3. don''t talk about things you have no clue about.
4. just because person X can do Y well using Z, doesn''t mean you''ll do Y well if you use Z.
corollary: don''t use words like "most people" or refer to particular groups of people when you''re justifying your opinions, if those groups do not include you.
5. authoritative statements require sensible proofs.
corollary: if you have no evidence to back yourself up, don''t post.

Share this post


Link to post
Share on other sites
yeah, yeah, C is faster than C++ isn''t really a fair statement to make. I''m not at all saying C++ is evil. But C++ has so many pitfalls that seem convenient that can kill performance. The first of which is i/o streams, the point of this post to begin with. There certainly can''t be many people out there who argue that the C++ implementation is efficient or robust. Number 2 target is the STL classes, which really don''t give me enough control over memory allocation to still make me feel like I have a good handle on how big my program is becoming. I am particularly disapointed with the regular STL classes that ship with g++, though i have heard good things about STLport. Next, the compilers are not yet up to par with the C compilers. A lot of the optimization is still based on the old C code techniques which don''t really apply to objects as well as they could. Finally, it is easy to accidently create redundant copies of objects when calling functions. If you pass and integer by copy, it''s not big deal. But passing an object, all of a sudden you have to allocate who knows how much memory, run the constructor code, etc. I know that most of this stuff is easily avoidable if you just pay attention to it. I know that if you put your mind to it, your C++ code will be running at about the same speed as your C code. But people forget, don''t care, or don''t know. When you''re working on a project with others and optimizing for speed, it makes you want to scream when someone hands you a file whose first line is
#include <iostream.h>
To me, it''s easy to write efficient code in C, but more difficult to make it OO. In C++, it''s easy to write well designed code, but there many pitfalls that would make it inefficient. While good code is a priority in all fields of CS, runtime performance is a higher priority in game industry than others. JAVA isn''t used by video game companies because it''s too slow, but certainly it is widely used. In web applications, for example. The rate determining step in DB programs is the disk read. Certainly letting a few hundred extra CPU cycles slip by between pressing enter and starting the search isn''t a big deal when the average disk read time 8ms. And kernels are written in C.

Share this post


Link to post
Share on other sites
quote:
Original post by Ready4Dis
All I did when switching to structs, was pulled all the functions out of them, and made the functions take a struct of that type, and this resulted in a 400% increase in rendering speed on average!).


hm.. what compiler? that is really unnormal..


class Obj {
public:
void sayHello();
};

Obj x;
x.sayHello();


and


struct Obj {
};

void sayHello(Obj* _this);
Obj x;
sayHello(&x);


actually WILL result in _EXACTLY_ the same code in the end.

that is only true if the calling convention of both functions is the same. for member functions, calling convention is normally __thiscall, wich is even faster, because the first parameter, the implicit this pointer, does not get pushed on the stack, but directly loaded into.. ecx? well, into a register..



this is not about c/c++, no one codes in c anymore. they code with c-style code in a c++ compiler, okay, but there is a) nearly no c-compiler for pc available anymore, and b) nearly no one who actually is so dump and would use it.

you can only gain from c++, never loose. your 400% speed drop is stupid. i''ve done several realtime raytracers with c++ on my old p3 500, all with classes, all nice fast and neat. if you use c++ correctly, it is fast. and with newest compilers, its even more fast. can''t wait for vs.net everett (vs.net 2003), with inlining over .lib files, automatic sse generation etc.. oohh i can''t wait:D

"take a look around" - limp bizkit
www.google.com

Share this post


Link to post
Share on other sites
(reply to the original post)

the way i solved slow file io is i created a class that has an interface somewhat like this


class MemoryBuffer
{
...
public:
MemoryBuffer(char * Filename);
MemoryBuffer();
~MemoryBuffer();

bool LoadFile(char * Filename);

DWORD Read(BYTE * Out, DWORD Size = 4);
void Write(BYTE * In, DWORD Size = 4);

...
};


then i would use it to load the file, the constructor loads it in big chunks so it loads faster, and then it has stdio style functions to read and write from the file in memory. when you are done you close the file, (delete the instance)

it works for most types of files, and a lot of libraries have a LoadFileFromMemory(...) function, so you can even use it in other libraries.

it also made file management in general easier, and it made it a lot easier to write file packing functions, basically just make a header with the filenames and offsets in the file and sizes, and write the MemoryBuffer to that offset. its really easy to load it back too.

Share this post


Link to post
Share on other sites
quote:
Original post by kdogg
yeah, yeah, C is faster than C++ isn't really a fair statement to make.


oh?
quote:

But C++ has so many pitfalls that seem convenient that can kill performance.


bad programmers != bad language. if you didn't see good c++ code, that doesn't mean that c++ itself is bad. you can say that it's complex, hard to use properly, etc. - these are all valid points. but not "c++ sucks because programmers don't learn enough of it and write crappy code." see davepermen's post.
quote:

The first of which is i/o streams, the point of this post to begin with. There certainly can't be many people out there who argue that the C++ implementation is efficient or robust.


efficient for what? formatted input? raw input? as compared to stdio? you can use streambuf directly if you so desire. and personally, i use file mappings and stay away from any crt i/o if i don't need formatted input. it's both easier and faster.
quote:

Number 2 target is the STL classes, which really don't give me enough control over memory allocation to still make me feel like I have a good handle on how big my program is becoming.


i'm not sure i understand. what exactly control do you need? is your code better than stlport's node allocator?
quote:

I am particularly disapointed with the regular STL classes that ship with g++, though i have heard good things about STLport.


so try it. why not?
quote:

Next, the compilers are not yet up to par with the C compilers. A lot of the optimization is still based on the old C code techniques which don't really apply to objects as well as they could.


you understand that unless you provide some proof this is a non-argument, don't you? see my post above.
quote:

Finally, it is easy to accidently create redundant copies of objects when calling functions. If you pass and integer by copy, it's not big deal. But passing an object, all of a sudden you have to allocate who knows how much memory, run the constructor code, etc. I know that most of this stuff is easily avoidable if you just pay attention to it. I know that if you put your mind to it, your C++ code will be running at about the same speed as your C code. But people forget, don't care, or don't know.


again, it's not the language's fault that people can't use it. if you don't like c++ because it's hard, fine, but saying that "i don't know how to do elementary things correctly and therefore c++ sucks" is childish.
quote:

When you're working on a project with others and optimizing for speed, it makes you want to scream when someone hands you a file whose first line is
#include <iostream.h>


and i'll scream when someone uses stdio to read one byte per call. simply not using iostream doesn't mean that your code is good. see the end of my post above.
quote:

To me, it's easy to write efficient code in C, but more difficult to make it OO. In C++, it's easy to write well designed code, but there many pitfalls that would make it inefficient.


you understand that this implies that you are not qualified to judge c++'s performance because you don't have enough knowledge of it, don't you?
quote:

While good code is a priority in all fields of CS, runtime performance is a higher priority in game industry than others.


another assertion without proof. you want me to believe this?
quote:

JAVA isn't used by video game companies because it's too slow, but certainly it is widely used.


please. stay on topic. java has nothing to do with the discussion because it's compiled to bytecode. c and c++ can be made to generate equivalent code, see davepermen's post.
quote:

In web applications, for example.


what do you suppose server-side implementations use? check out some stuff that ms has in asp.net, you might be surprised.
quote:

The rate determining step in DB programs is the disk read.


we have disk caches. and databases are more complex than fetching bytes off the disk. along the same line of thought, speed of a game can be said to be determined by speed of graphics api such as directx. will you buy this and use c# for coding games that are primarily concerned with drawing stuff on screen (ie, simple ai/physics/etc)?
quote:

Certainly letting a few hundred extra CPU cycles slip by between pressing enter and starting the search isn't a big deal when the average disk read time 8ms.


not every db query goes to the disk. get a clue.
quote:

And kernels are written in C.

and thus are not optimized?


[edited by - niyaw on March 6, 2003 4:17:45 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by Magmai Kai Holmlor
The stdio functions are part of C++ so it''s not slower than C.
Many aspects of C++ are faster than C (inlining, functors, and template).

Random minor correction: inline functions have been part of standard C for four years now.

Share this post


Link to post
Share on other sites
Thanks for all the replies (sorry for starting this age old war up again).
I re-wrote the code to read the header and then the rest of the file but I''m still noticing diffrence in loading times (enought that I can mesure it with just a wrist watch). Oh well, the C way works as well I guess, just thought it be nice to have everything in C++.


--
Spearhawk productions
Project Andromeda

Share this post


Link to post
Share on other sites
alright niyaw, now you''re just being a dick. I''m simply stating why i prefer C dialect over C++. It''s really not open to discussion. I wasn''t aware that i''d have to provide a bibliography for my own personal decisions. The point of the whole post is that i/o streams in C++ are slower than the stdio counterparts. Until you can contradict that, don''t bother responding.

Share this post


Link to post
Share on other sites
"no one codes in c anymore. they code with c-style code in a c++ compiler"

Actually, I have a pure C compiler on my machine right now (an old MS one). But I''m a luddite. ;-)

"Many aspects of C++ are faster than C (inlining, functors, and template)"

I have inline functions. Heck, I seem to recall using them back in the Turbo Pascal days! Unless something else was meant by inlining?


Spearhawk: could you post both the C and the current C++ versions? If you''re reading the file as a block, and the algorithm is identical, it seems that it should take pretty much the same amount of time in both!

Share this post


Link to post
Share on other sites