do you have any preferences? I'm stuck with my voxel engine when it comes to speed and I thought maybe there are better compilers out there than the one from MSVC++ 6SP3.
ALso, do you think that switching from C++ to C would be worth the effort?
(I know the best would be to switch from C++ to Assembly :-))
thanks
Sebastian
Awesoken at
I use MSVC6 SP5 with "Processor Pack" for all "Win32" projects on my website:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
It shouldn't make any difference whether you use C or C++ syntax. I use C simply because I'm more familiar with it.
BarrenSoul at
Ken whats your opinion on microsofts VC++ express 2005 IDE? is it any good compared to VC++6.0?
Silhouette of a Can at
I currently use version 7. It has a couple more features than 6, but it's nothing really special. I wouldn't see any reason to go buy another one if you already got 6. I haven't used 2005 yet.
Awesoken at
I don't use the VC IDE even though it's installed on my machine. It takes too much time to set up a new project and it creates way too many temporary files. I still do things the old way - by writing my own makefiles and compiling at the command prompt. I use KC.EXE for all my text editing. Much like the VC IDE, KC has a quick key (F5) for compiling and running inside the environment.
Are you talking about the Visual C++ 2005 Express Beta? I actually tried it once. When I realized that it didn't include "windows.h", I lost interest. It seems as if Microsoft thinks everybody is going to switch to .NET. Sorry, but "managed" DirectX really sucks. Not including the Win32 API in their next compiler would be a mistake.
As for the IDE, I could care less. They're all annoying if you ask me. I always find myself looking for some simple feature and getting lost in the menus. I'd rather spend my time looking through abbreviated command line help than right-clicking on every pixel of the screen, hoping to get the right dialog.
pwroberts at
Are you talking about the Visual C++ 2005 Express Beta? I actually tried it once. When I realized that it didn't include "windows.h", I lost interest. It seems as if Microsoft thinks everybody is going to switch to .NET. Sorry, but "managed" DirectX really sucks. Not including the Win32 API in their next compiler would be a mistake.
I'm sure this is just because it's the "Express" edition. If you point it at an existing installation of the Platform SDK (e.g. the one that shipped with your previous version of VC) then it works just fine.
My personal gripe with VC2005 is the lack of support for SourceSafe. SS may be ancient, but it works, and I still use it. I guess it's possible that the Professional/Enterprise editions of VC2005 will support it, but I have a nasty feeling that SourceSafe has finally been dropped in favour of MS's new "Team System" super-mega-hyper-source-control solution thingy. Team System might turn out to be awesome, of course, but I fear it'll be overkill for a one-man development outfit. Maybe I'll just switch to CVS or subversion.
Regarding the original topic, if you haven't looked at the free Visual C++ 2003 Toolkit, then give it a go. It contains the (command line) compiler from VC2003, which rocks. Far improved template support, global optimisation, and other pretty things.
Silhouette of a Can at
Awesoken said
I don't use the VC IDE even though it's installed on my machine. It takes too much time to set up a new project and it creates way too many temporary files. I still do things the old way - by writing my own makefiles and compiling at the command prompt. I use KC.EXE for all my text editing. Much like the VC IDE, KC has a quick key (F5) for compiling and running inside the environment.
Are you talking about the Visual C++ 2005 Express Beta? I actually tried it once. When I realized that it didn't include "windows.h", I lost interest. It seems as if Microsoft thinks everybody is going to switch to .NET. Sorry, but "managed" DirectX really sucks. Not including the Win32 API in their next compiler would be a mistake.
As for the IDE, I could care less. They're all annoying if you ask me. I always find myself looking for some simple feature and getting lost in the menus. I'd rather spend my time looking through abbreviated command line help than right-clicking on every pixel of the screen, hoping to get the right dialog.
I don't know if I could have said it any better. VC7 lacks many include files and I had to end up copying all of my ones from 6 over to 7 to be able to recompile my older programs. There's no fstream! Well, there's something is called just "fstream", but they altered it and it's not even close to what it was before. They did this with alot of others as well. Microsoft likes to push everyone around whenever they feel like it. Sure, .NET is nice, but don't try to wipe out the existence of the old stuff. Besides, it seems the only real use for .NET is to make tools being as it's all compiled at run-time.
I use the IDE though. But I've always been used to IDEs and hate compiling from the command prompt.
Anonymous at
i use GCC, its far better at optimization than VC++!!! And its free! IM NOT paying no cent to the evil empire!!
Anonymous at
Re: ken, which compiler do you use?
Sebastian said
Ken,
do you have any preferences? I'm stuck with my voxel engine when it comes to speed and I thought maybe there are better compilers out there than the one from MSVC++ 6SP3.
ALso, do you think that switching from C++ to C would be worth the effort?
(I know the best would be to switch from C++ to Assembly :-))
thanks
Sebastian
Of course you should switch to C, all those virtual functions, inheritance, etc. makes C++ bloated! The key is to use C where speed is needed ;)
jspenguin at
ken, which compiler do you use?
I use GCC because I use Linux. Whenever I compile for Windows, I use MinGW (which is based on GCC). A lot of my code, especially my SDL apps, can run unmodified on Windows if I use MinGW. If I used VC++, I would have to make quite a few compiler-specific changes.
Silhouette of a Can at
Re: ken, which compiler do you use?
Anonymous said
Of course you should switch to C, all those virtual functions, inheritance, etc. makes C++ bloated! The key is to use C where speed is needed ;)
You're dissing inheritance?
Mblackwell at
Silhouette of a Can said
You're dissing inheritance?
Yes... yes I believe he is.
Frobozz at
ken, which compiler do you use?
I do the same as jspenguin does (I've got the Slackware distro). :wink:
At the risk of insulting all of them... guest: How is it bloated? :lol:
Anonymous at
WatcomC/C++ 10.0-11.0 + MultiEdit 7.0 - nice!
Since Watcom didn't have it's own IDE (like Borland compilers)
it was pretty nice to use MultiEdit as code editor.
It had a hot-key binding possibility for compiling and running inside it too.
I think that if Watcom had just included MultiEdit as a part of their package
the problem with IDE would be resolved!
Ken, what text editor for code editing had you been using to write code for Watcom compilers, before you wrote KC.EXE?
Awesoken at
what text editor for code editing had you been using to write code for Watcom compilers, before you wrote KC.EXE?
Before KC.EXE, I used QC.EXE, a text editor that was included with Microsoft Quick-C. I never used the built-in C compiler from Quick-C though. I used it because it had in-line help which was quite useful. For example, you could press F1 on "printf" and it would show the syntax just like in QBASIC. This feature was rather unusual at the time.
In August of 1995, BUILD.TXT and ENGINE.C were reaching the limits of QC's memory. It was very frustrating to make changes and have "Out of Memory" errors undo them. In these times, most people would have either found a new editor, or split the big files into lots of little ones. Not me, though. I decided it was better to write my own text editor rather then learn something new. If I wrote my own editor, I could guarantee that I would always be comfortable in any environment. Also, I had some ideas on how to write a good text editor. About 2 days later, I was using my very first version of KC.EXE for DOS. It featured smooth-scrolling 80x25 text ... everybody at 3D Realms thought I was insane : )
maniac1701 at
whats the difference between smooth scrolling and regular scrolling?
my guess is that the speed slowly increases to the full speed the the scroll but im curious my self.
i've been told by one of my college professors that im insane for writing programs in dos so i know how that feels
Silhouette of a Can at
I don't see the point for smooth-scrolling in a text editor either. Ken, I think you are crazy.
Awesoken at
By smooth scrolling, I meant that the step size is 1 pixel, and not the width or height of the font. In fullscreen 80x25 text mode, 1 pixel scrolling is rare because it requires the use of some video registers which must be written during the vertical retrace.
Don't doubt the benefits of smooth scrolling text. It's just easier to follow with your eyes when the minimum step size is smaller.
Silhouette of a Can at
Well, with all the years I've been using text-sized scrolling editors, this one makes me dizzy. I'm virtually immune to car sickness, but then I can get motion sickness really easily while swinging. But it's more my problem than yours. If I made one with my own preference it'd be quite different.
maniac1701 at
hmm interesting i'll have to check it out. i hope you have src posted cause i would like to see how you can move text only 1 pixel at a time. i didn't think this was posible.
GothOtaku at
maniac1701 said
hmm interesting i'll have to check it out. i hope you have src posted cause i would like to see how you can move text only 1 pixel at a time. i didn't think this was posible.
You render the text as a pixel image and move the image up 1 pixel at a time.
maniac1701 at
i thought it was a text mode editor (non graphics resolution). if this is true then rendering the image and shifting it up by 1 pixel(by reading graphic data) is imposible. but if it does use a graphics resolution then i know how to do this.
Edited at
maniac1701 at
yeah i was right it does use the text mode (i can tell cause it runs in a window in xp and no gfx reses will run that way). How did you do that ken? i would love to see the src for that.
Awesoken at
I do not have that code public, but I'll extract the parts you care about (and simplify it a bit). By default, KC uses a 9x16 font. This is how I shift the screen with pixel resolution:
...
while (inp(0x3da)&8);
while (!(inp(0x3da)&8));
outp(0x3c0,0x33); outp(0x3c0,x); //x ranges from 0 to 8
outp(0x3d4,0x08); outp(0x3d5,y); //y ranges from 0 to 15
...
I do the rest of the scrolling by preparing an 81x26 size text buffer and then copying it to the screen using a memcpy. I need to prepare 1 extra row and column for when the character boundary isn't aligned. The windows version of KC uses graphics mode, of course.
maniac1701 at
wow cool effect especially on my laptop (the text gets blury) but its interesting to use that procedure with random coordinates. you can make the screen shake like mad.
now if i could just get the keyboard polling procedures..............
dx at
FWIW, Visual C++ 2005 includes an x64 and IA64 compiler (in addition to x86 and .NET), so for that alone it ought to be worth considering.
Note though that I'm not sure if the actual Visual C++ 2005 Standard/Express will include it when they finally release it to retail, but if you go for Visual Studio 2005 it definitely will. (The VC++ 2005 Express only includes x86 and .NET I think, I haven't tried it, heh).
Might be interesting to see what kind of things you can do with (for example) PNGOUT under native x64. :D
Awesoken at
Might be interesting to see what kind of things you can do with (for example) PNGOUT under native x64.
I don't see how native 64-bit code would open up any new opportunities for optimization in PNGOUT. What PNGOUT needs is a new algorithm. Going from 16-bit to 32-bit was a big leap because most programs were already requiring more than 64KB of memory at the time. Going from 32-bit to 64-bit may be important in a few years, but until common systems exceed 4GB (or perhaps 2GB) of memory, and programs actually use that much, it's not going to make much difference.
Really, the main benefit of x64 or IA-64 is accessing memory without segmentation. The other benefit is true 64-bit integer math, but I can't think of any programs of mine that need that right now. I'm sure once I have it, I might think of ways to take advantage of the extra precision... but until then, I'm quite happy without it. MMX already gives IA-32 applications most of the 64-bit capabilities, such as copying or clearing memory 64 bits at a time. I find that things like MMX, SSE, and HyperThread technology have much more potential for optimization in common applications than x64 or IA-64. Even so, it's a step in the right direction, and everyone's going to need it eventually.
BarrenSoul at
I know a method that generalizes to all hypergeometric series which involves only integer coefficients and makes them alot faster
"Most classical series formulaes to compute constants (like the exponential series for e, arctan formulaes for p, Chudnovsky or Ramanujan formulaes for p, ...) have a time cost of O(n2) to compute n digits of the series using a classical approach. This approach usually permits to evaluate such series in time O(n log(n)3) (or O(n log(n)2) for e), which is much better."
or what kind of math is your program doing (like what is the bottle neck) mabe I can find an algorithm or method which could improve it (I'm good at finding stuff)
Anonymous at
Awesoken said
I don't see how native 64-bit code would open up any new opportunities for optimization in PNGOUT.
x64 provides 8 additional GPR's-- if register pressure is a problem with your code (moving variables in to or out of memory constantly rather than keeping them in a register) you might see a benefit from x64. =)
MMX already gives IA-32 applications most of the 64-bit capabilities, such as copying or clearing memory 64 bits at a time. I find that things like MMX, SSE, and HyperThread technology have much more potential for optimization in common applications than x64 or IA-64. Even so, it's a step in the right direction, and everyone's going to need it eventually.
Sure, absolutely agree. But for code that's register dependent and can't be made to (easily) benefit from SIMD techniques, those eight extra GPR's are sure nice. :P The additional XMM registers don't hurt either, heh.
If you rely on assembly a lot there's also ML64 (MASM for x64) available (though you may end up rewriting much of the code simply to take advantage of the additional GPR's).
Awesoken at
Wow, you're right. 16 general-purpose registers is definitely a big advantage. I suppose I was too focused on the 32->64 bit thing for integer math. When I have access to a machine with EM64T, I'll definitely have to try things with it : )
masterlee at
Awesoken said
I don't see how native 64-bit code would open up any new opportunities for optimization in PNGOUT. What PNGOUT needs is a new algorithm. Going from 16-bit to 32-bit was a big leap because most programs were already requiring more than 64KB of memory at the time. Going from 32-bit to 64-bit may be important in a few years, but until common systems exceed 4GB (or perhaps 2GB) of memory, and programs actually use that much, it's not going to make much difference.
There are actualy some aplications that whould mage use of that much memory. On the one side The SAS System curently some people produce 10 GB or greater for example sorting such amount of data use long time. On the other sides aplications like realtimer raytracer with enabled realtime radiosity need very high amount of memory.
dx at
Awesoken said
Wow, you're right. 16 general-purpose registers is definitely a big advantage. I suppose I was too focused on the 32->64 bit thing for integer math. When I have access to a machine with EM64T, I'll definitely have to try things with it : )
Sorry for the late reply, I should visit here more often, heh. I was going to add that the additional 8 registers are byte/word addressable (e.g. - just as you can access AX or AL/AH, you can access the lower 16/8-bit parts of these new registers). Not knowing how your code works, I'm not sure if this is important or not, but thought it might be useful to note. ;)
Worst case scenario though, just a straight recompile of the C code with the x64 compiler could yield a 5-10% improvement without any changes at all. And FYI: if you download the Microsoft Platform SDK for Windows Server 2003 SP1 you'll get both the x64 and IA64 compilers free (look in the \bin\win64\ for cl.exe for IA-64 (ias.exe is the Itanium assembler FYI) and look in \bin\win64\x86\AMD64\ for cl.exe for x64 (ml64.exe is the x64 MASM FYI). They're cross compilers too, so you can run them on any ol x86-based system.
Maren at
Re: ken, which compiler do you use?
Awesoken said at
I use MSVC6 SP5 with "Processor Pack" for all "Win32" projects on my website
Any particular reason for using SP5 instead of SP6? Thanks :)
And sorry for having resurrected this zombie thread, just in case you actually mind. Starting a new one for something that's aready there just seemed pointless to me.
Awesoken at
1. I didn't know VC6SP6 existed. I just assumed M$ dropped support after the release of VC7. 2. I found this out just now: SP6 removes the processor pack!
Extracted from the readme file of Vs6sp6.exe:
We've made several improvements to Visual C++ 6.0 ... the Visual C++ Processor Pack (VCPP) was removed from Service Pack 6. If you have the VCPP installed, installing SP6 will remove it from your machine.
Nice. So removing everything I care about is an improvement? I use inline SSE instructions a lot. Without support, nearly all of my programs would break. Yes, I can always compile with a newer version of Visual C. The reason I still use VC6 is because you can assume everybody has a copy of "MSVCRT.DLL" in their system32 directory. Using the /MD option, you can produce very small executables (below 4KB for example). If you do this with a later versions of VC, they may get a DLL not found error.
Maren at
Ken = 1 MS = 0 ;D
It turns out that code-iliteracy is becoming the next analphabetism. In some way it's like being foreign in a country the size of the world.
After doing a relatively large research and having considered different languages, compilers and arguments against, I've decided to get started with C++ (thought of C first, but "apparenlty" the gains performance-wise are marginal) and stick to VC6, avoiding the unnecesary bloating introduced in .NET. Whether I've chosen right or wrong, time will tell.
Zardalu at
Awesoken said at
1. I didn't know VC6SP6 existed. I just assumed M$ dropped support after the release of VC7. 2. I found this out just now: SP6 removes the processor pack!
Extracted from the readme file of Vs6sp6.exe:
We've made several improvements to Visual C++ 6.0 ... the Visual C++ Processor Pack (VCPP) was removed from Service Pack 6. If you have the VCPP installed, installing SP6 will remove it from your machine.
Nice. So removing everything I care about is an improvement? I use inline SSE instructions a lot. Without support, nearly all of my programs would break. Yes, I can always compile with a newer version of Visual C. The reason I still use VC6 is because you can assume everybody has a copy of "MSVCRT.DLL" in their system32 directory. Using the /MD option, you can produce very small executables (below 4KB for example). If you do this with a later versions of VC, they may get a DLL not found error.
Yes, I found this out the hard way, too. I already hated Visual C++ 7.0, 7.1, and 8.0 because of Microsoft's decision to no longer have a "universal" msvcrt.dll but a customised version for those compilers. Yes, those compilers may produce faster code, but I myself went back to 6.0 because of the lack of compatibility. Microsoft obviously wants "everyone" to be able to write code, no matter how bad, while really good code can only be written by a few...
'nuff said.
Ben Jos.
jokluge at
Awesoken said at
2. I found this out just now: SP6 removes the processor pack!
Apparently you can fool the the Processor Pack by editing the registry: http://support.microsoft.com/default.aspx?scid=kb;en-us;872907 This dirty hack recommended by Microsoft makes me smile.
Awesoken at
There's an easier work-around: when you install VCPP, copy the files from its temporary directory before clicking 'ok' to accept the error message. You really only need 1 file: "c2.dll". The problem is, I think that's where most of the compiler logic exists. In other words, if you installed VCPP over SP6, it's quite likely that it would result in the same thing as installing VCPP over SP5. I've tested later versions of VC (> VC6), and I yet to see a bug fix for this case:
#include <stdio.h> //Demonstrates Visual C bug: //Compile with /Og, and the output is: -30,-20,-10,0,10, // Correct output should be: 0,10, int main (int argc, char **argv) { signed long i; for(i=-3;i<=3;i++) if (((unsigned long)i) < ((unsigned long)2)) printf("%d,",i*10); return(0); }