Learn some assembly

[jjp]

When you shoot the assembly programming down as an unnecessary thing, consider that while it may be completely useless to you, that doesn't mean it is useless for everyone.

I've never said that assembly is a useless skill in general, obviously there are quite a few applications (compilers, embedded systems..). I am just saying that most of the time using assembly for performance reasons is a waste of time when high level languages are available.

[Nauk]

I believe that with each version software should be made to work faster and better on the same hardware. In version 2 of something you find the bottlenecks, have had time to research new algorithms, learnt new optimising tricks, etc. Like how games on a console years after release are much more technically advanced than when the console is brand new, because the coders learn to take advantage of what they have better. But Windows doesn't go like that. Instead of optimising what's there, they just add more on top, requiring better hardware to keep the old stuff going.
Assembly won't help, it's the operating system that causes most of it. Although maybe windows should be written in assembly...

Exactly my thought - I remember times when people tried to get the absolute max out of the very little resources they had and came up with astonishing unconventional innovations driven by that, I sometimes wonder where that spirit went. (Not implieing that I can even remotely live up to that myself )

Hard disks haven't gotten much faster. That is one major point where bad responsiveness originates from. C++ compile times are high because C++ compilers are that good at optimizing. Take a C++ compiler from 10 years ago and it will run super fast in comparison. But the code produced will be a lot worse. And C++ isn't exactly a language designed for fast compilation times. Work with C# (for example) and you won't be having any forced breaks due to recompilation
Also, you're not really getting the whole picture here. If you'd compare equally complex software from today and from 10 years ago you might as well note some differences in terms of reliability and security, for example.

Harddisks have gotten a lot faster in the last 20 years and I really don't think that has anything to do with it, anyway with the rest you sure got a clear point, but I don't think that covers it all, only to a certain percentage.

As for the slow C++ compile times syedhs answer probably covers that one:

Hmm isn't the prime reason C++ compilation is slow even on fast pc because of template? Try compile a plain .C file - it is stupid blindingly fast!

Work with C# (for example) and you won't be having any forced breaks due to recompilation

No thanks - I had to work with it almost 2 years daily, the language is nice, and with the huge application we developped with it a full recompile still was a coffee break. Besides imho one of the reasons for nowadays still slow applications is the extensive use of C#, Java or other pseudo-compiled byte-code interpreted runtime based languages. If i have to take compile-time breaks then I want at least want native x86 machine code as result, otherwise I prefer a oridinary oldschool interpreted language anyday because that grants really speedy development and quick changes. If it really has to be then Java has the clear advantage tho, it is nearly flawlessly crossplatform able and you still can compile it to x86 native.

I think at this part of the discussion it is time for some hard numbers, I have already looked around a bit but I couldn't find any benchmark charts on the subject at all, just discussions not being backed up with numbers and data. Doesn't anyone have a good link or chart somewhere stashed away or bookmarked?

Oh and another one for nostalgias sake:

[jjp]

C# code is never interpreted

Harddisks have gotten a lot faster in the last 20 years and I really don't think that has anything to do with it

If you compare the speedup with how much CPUs have gotten faster really not that much has happened on the hard disk front. Also the problem isn't throughput but the initial latency of a disk read/write.

[Nauk]

Ok maybe I have to clarify and define first what I meant when I said my impression is that apps are way slow for the raw hardware power gain over the years, that impression does not come from the disk access but from the speed they respond to user input, even when there is no harddrive access, just so we talk about the same thing and are not missing eachother

[jacmoe]

C# code is never interpreted

Semi-ly so. It's compiled to CLR, and therefore you cannot compare the compile time of C++ with C#.

If you're not using any STL (Boost is a killer), then C++ compiles are really fast.

@Nauk:
Yeah, Guru Meditations are cool!

[Kojack]

For a good example of why c++ is slow to compile, turn on saved preprocessor output. Visual Studio will save a *.i file which contains the actual source code passed to the compiler (the compiler stage never sees stuff like includes, only the preprocessor stage does).

My spherical harmonic demo has a single source file: a 695 line cpp.
The generated .i file is 548741 lines of c++ (ok, a lot of blank lines, but it's still huge. 3.7MB of text). That's what's really being compiled. Precompiled headers and stuff help with that of course.
I've had simple ogre apps hit a million lines of code, based on what headers I've included, even if I didn't use them.


Another big problem with hard drives is that windows doesn't always do things in an efficient way. For example, searching for a file by name.
On my previous computer (Athlon X2, Windows XP, around 1.5 terrabytes spread over 6 western digital sata hard drives and 12+ partitions) doing a simple file search for a single word in the filename took about 1.5 hours.
Doing the same search on the same drives and finding the same results using SearchGT (a shareware tool) takes under 45 seconds. That's with no caching, no indexing, run straight after installing the program for the first time. It goes straight to the lowest level raw access to ntfs, bypassing all the windows crap.

[_tommo_]

Couldn't find the .i, but the precompiled dependecies are 67.3 mb for my game

[Kojack]

The option is under project properties in C++ / Preprocessor / Generate Preprocessed File.
You can set it to No (the .i is never actually saved, it's fed directly into the compiler), Without Line Numbers and With Line Numbers.
The .i will end up in the same directory as your vcproj file.

The other fun option is C++ / Advanced / Show Includes. Turn that on and the compiler output will recursively list every include as it's included. It will look something like this:

Code: Select all

1>Note: including file: F:\work\qgf4_0.011\components\ogre\ogremain\include\OgreTexture.h
1>Note: including file:  f:\work\qgf4_0.011\components\ogre\ogremain\include\OgrePrerequisites.h
1>Note: including file:   f:\work\qgf4_0.011\components\ogre\ogremain\include\OgrePlatform.h
1>Note: including file:    f:\work\qgf4_0.011\components\ogre\ogremain\include\OgreConfig.h
1>Note: including file:   C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\string
1>Note: including file:    C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\istream
1>Note: including file:     C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\ostream
1>Note: including file:      C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\ios
1>Note: including file:       C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\xlocnum
1>Note: including file:        C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\climits
1>Note: including file:         C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\yvals.h
1>Note: including file:          C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\crtdefs.h
1>Note: including file:           C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\sal.h
1>Note: including file:            c:\program files (x86)\microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h
1>Note: including file:           C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\crtassem.h
1>Note: including file:           C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\vadefs.h
1>Note: including file:          C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\use_ansi.h
1>Note: including file:         C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\limits.h
1>Note: including file:          C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\crtdefs.h
1>Note: including file:        C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cstdio
1>Note: including file:         C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\stdio.h
1>Note: including file:          C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\crtdefs.h
1>Note: including file:          C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\swprintf.inl
1>Note: including file:        C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cstdlib
1>Note: including file:         C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\stdlib.h
1>Note: including file:          C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\crtdefs.h

except for my sh demo it's over 1000 lines like that.

[_tommo_]

I compiled with that options... i have 107 mb of .i files, and 37279 includes
I think the weight comes from PhysX + Ogre, wich are included in most of the files...

[Nauk]

Another big problem with hard drives is that windows doesn't always do things in an efficient way. For example, searching for a file by name.
On my previous computer (Athlon X2, Windows XP, around 1.5 terrabytes spread over 6 western digital sata hard drives and 12+ partitions) doing a simple file search for a single word in the filename took about 1.5 hours.
Doing the same search on the same drives and finding the same results using SearchGT (a shareware tool) takes under 45 seconds. That's with no caching, no indexing, run straight after installing the program for the first time. It goes straight to the lowest level raw access to ntfs, bypassing all the windows crap.

And there you would think one of the most successful companies in the world should be able to afford quality coding and problem solving, I really wonder sometimes what the people working for M$ are doing all day long.

[Kojack]

I really wonder sometimes what the people working for M$ are doing all day long.

Watching youtube and looking at stupid cat pictures like the rest of us.

[Nauk]

Or maybe they secretly invented 10 new methods to pick your nose more effective and they keep it to themselves! - bastids

[nikki]

Ok, now I'm on to hooked to Lisp. Next I'm checking out Forth.

(I'm on a run to see what cool ideas there are in different langauges)

[Kojack]

Forth is great. If you get the hang of it, give False a try. http://en.wikipedia.org/wiki/FALSE
Then if you haven't gone insane from stack based languages, give Piet a try. http://www.dangermouse.net/esoteric/piet.html

[Nauk]

FALSE is an esoteric programming language designed by Wouter van Oortmerssen in 1993, named after his favorite Boolean value. It is a small Forth-like stack-oriented language, with syntax designed to make the code inherently obfuscated, confusing, and unreadable. It is also noteworthy for having a compiler of only 1024 bytes (written in 68000 assembly). According to van Oortmerssen, FALSE provided the inspiration for various well known esoteric languages, including brainfuck and Befunge.

haha

[nullsquared]

If you're not using any STL (Boost is a killer), then C++ compiles are really fast.

Actually, even with Boost and the SC++L, C++ compiles crazy fast. I've found that Ogre is that one library I use that kills compile speed completely (and link speed, too).

[lonewolff]

I actually started playing with 32bit assembly today. So, far so good.

I dont know how I will go not having access to classes and the like though

[Vectrex]

If you're not using any STL (Boost is a killer), then C++ compiles are really fast.

Actually, even with Boost and the SC++L, C++ compiles crazy fast. I've found that Ogre is that one library I use that kills compile speed completely (and link speed, too).

Do you use precompiled headers for Ogre? That mostly solved it for me

[lonewolff]

An interesting observation...

I am using VS.net 2008 Express as my IDE of choice.
I have created a C++ app using pure Win32 API calls to create a window, an edit box, and a button.
When you type in the edit box and press the button, the contents of the edit box is echoed in a message box. Pretty simple.
The end result is a ~30Kb file that requires VC runtimes (1.7Mb) to be installed on any other system for the app to run.

I have just programmed the same application in assembly.
The end result is a 2.5Kb file that requires no additional runtimes installed whatsoever. I just tested on a clean install of Windows XP SP1, that has no windows updates at all

So thats it.

C++ 30Kb + 1.7Mb overhead
Vs
Asm 2.5Kb (Total)

For the same application!

How cool is that!

[Owen]

If you want evidence that hand optimized assembly is still important today, go and talk to the x264 guys. They seem to spend most of their time hand optimizing their code with the millions of vector math extensions that processors have these days Of course, H.264 encoding/decoding is a bit of a pathological case

They also, of course, spend their time optimizing their C to help the compiler optimize it better, but in some cases, you can't beat hand written assembly

[Nauk]

C++ 30Kb + 1.7Mb overhead
Vs
Asm 2.5Kb (Total)

For the same application!

How cool is that!

Totally in my book - one of the things that keeps me poking around in the language

I have found a pretty interesting conversation on the subject while i was googling for something entirely different - good read:
http://www.pldesignline.com/howto/20100 ... JVN?pgno=1

[syedhs]

They seem to spend most of their time hand optimizing their code with the millions of vector math extensions that processors have these days

To be honest, it sounds like a 'delicious' job to me. Millions of vector math with optimized assembly

If you really want super-tiny executable size, then use Debug(.exe/.com?) packaged in MSDOS. Yes MSDOS, not windows DOS. You can produce as small as 10 bytes COM application (I dont know really the smallest size possible, but 20 bytes are definitely attainable). Okay not the Component Object Model but an executable with extension .COM that uses TINY memory model - hehe bringing me back the nostalgia of using Turbo C 1.5. Tiny Memory Model was hot back then in 16 bit application where you can't access more than 65K of RAM as one variable, unless of course you use the huge modifier. Tiny Memory Model packs the both executable code and data segment into only one segment therefore limits the executable size to < 65K.

[lonewolff]

Yep, debug.exe is where is started for me.

Switching graphics modes in 4 lines of assembly. Those were the days.

Unfortunatly, there is not really a big future in 16 bit assmbly. As people who own 64 bit windows wont be able to run it due to lack of 16 bit subsystem.

[Kojack]

Unfortunatly, there is not really a big future in 16 bit assmbly.

Maybe not on pc, but on other platforms it's still useful. The ARM cpu has both Arm (32bit) and Thumb (16bit) instruction sets, and you can switch between them at any time based on the lowest bit of the address of a jump instruction. Thumb instructions allow you to pack a lot of functionality into a much smaller space, and can run better on certain memory types. Arm code is more powerful than thumb code, but working with 32 bits can have an unneeded overhead.
Arm chips are all over the place these days.

[reptor]

There is also some funny (well, to me) ways to get really small ELF files (Linux executable). I recall it includes stuffing code into parts of the file where it in fact shouldn't be but it still works, and removing sections which are not used by anything (in current Linux systems). There is an article about it somewhere, perhaps "tiny linux executable" search brings it up if you want to read.