Sure you can write more optimized code in Assembler than in c - and thats kinda the point. You don't write a c-snippet and go like 'hey now im gonna compile this by hand'...
Todays desktop CPUs(all CISCs anyway) still have ways of adressing and tricks in general you couldnt dream of in C. Needs a buttload experience though - but fairly possible!

I never said that you can't write slow C code, I said that its nearly impossible to write better assembler than a compiler. Of course this depends on the compiler, I have no doubt that its totally possible to write better assembler than the Lite-C compiler, but better assembler than GCC or LLVM/Clang?

But if by "better" you actually mean easier to read, you are right, that is possible.

Automated optimizations is a topic in the theoretical computer science for a very long time - fact is every optimization done by a toadys machine is obviously imperfect.
(In this case) every compiler has to make assumptions based on the higher language its interpreting. I remember one of the first examples we had in theoretical CS was a floating operation in which the compiler has to assume that you need - lets say 32 bit precision - the compiler has no way of knowing that u might need less, thus ends the optimization. Though this very basic and very old example might not work for any machine theres tons of literature about this.
In fact this exact problem was the reason for (re-)inventing RISC CPUs which try to minimize such problems.

If ure really interested in this topic I suggest u read some books about formal languages and numerical optimizations f.i.

EDIT:
You might try this
http://en.wikipedia.org/wiki/Kahan_summation_algorithm

Of course, but this doesn't mean that humans can do it any better and thats the reason why I still doubt that texcoord3 can produce better assembly.
You know, knowing that compilers aren't perfect and making it better are two totally different pairs of shoes.
No doubt that there are people who can do this, but what are the odds that one of them is here in the forum where most can't even write performant C code? If he had said that he optimized a very few routines in assembly, I would actually believe him, but a complete project? Are you really believing this?

About your floating point example, imo the user should know what kind of data type s/he should use in which case and the compiler should trust that the user knows what s/he is doing. Again, its totally easy to write horrible slow C code that even if optimized by the compiler still performs very bad, however, that was never my point.

I admit I have no idea what this thread is actually about neither have i any indea what texcoord is capable of...sorry for that.

Of course your totally right that its bogus to write a whole project in Assembler or thinking that you can even get close to the average power of compiler-optimizations these days.
But my point is - theres actually real life examples where assembler has a clear advantage over c - especially in computer graphics.
You are the local Apple-fanboy right? So you might have already stumbled over this:
Lets say u want to multiply two 32bit floats to a 64bit result and then get the middle 32bit. ARM processors can do that wihtin one clock-cycle((Prozessor-)Takt, ka ob das die korrekte Übersetzung ist) meaning using one assembler instruction. I don't know a single C-compiler who recognizes this and optimizes it correctly.

there're certainly compilers that have an ARM backend which use the power of specialized instructions. It is indeed a very daunting task for the compiler to identify several instructions that can be replaced by SSE instrunctions, though. It's all possible but it's also NP complete most of the time which is why sometimes writing a little asm doesn't hurt instead of having a compile time of several days.

EDIT: clock cycle is correct

Guilty as charged.


I did a quick look into the ARM ARM and couldn't find such an instruction in the NEON instruction set reference for any revision of the Cortex A8. Mind pointing me to the one you mean?

Btw, do you really mean one clock cylce or one assembler mnemonic?



FWIW: The * operator of my color class uses something that can be optimized by NEON quite well, by just loading both single precision floating point vectors into NEON registers at once and then multiplying them all at once. In fact, LLVM/Clang 3.0 does this when compiling for armv7 in release mode. I'm not quite sure which parameter triggers this, but one certainly does it.

Used LLVM Version:

Ok, well I am no God and I am not the most experience programmer in the world.

BUT,
I have tested various code snippets against gcc and vc++ (yes it's c++ but anyway...).

I've noticed that I can code very complex optimizations in assembly that the compilers destroy, mainly when it comes to accessing memory.

For example, my prime optimization is a ray-triangle intersection routine that only reads each possible triangle from ram and then does ALL of the math in registers. Now... maybe a compiler can do that, but at least gcc nor visual studio's compiler produced anything near as efficient.

To be honest, most of, if not all, of the optimizations I have made/plan simply manage variable better than c/c++. While that doesn't always translate to huge gains, or even different code from the compiler, in many examples, such as my ray-tracer, it is a very significant (I am still testing for how significant) difference. I've observed that accessing memory is not particularly fast compared to basic add,mult, etc and so the more I can keep in the cache and use registers, the faster the routines should be.

Also mk_1 noted about SIS (special instruction sets). Indeed I can use these and manage portability in the installer.

Again, I'm not an expert, just a obsessive coder. lol.

I find your comments about my coding ability mildly offensive. :{

Have I done something to suggest I am not able to achieve such a project?

Also, you must remember that the project will never be fully (or probably not even mostly) in assembler. At this point I'm just writing many routines in assembler language.

I'm very disappointed in your comment. I have only returned to contribute and ask nothing in return. I am not asking for money nor do I need any. I have been studying computer science since I was able to read. I take my work very seriously. while I might not be the best, I don't think I should be considered a novice.

I am a student at the University of Maryland and I take my honor very seriously. I would never exaggerate or forge results or code and to do so would mean my expulsion from my University. Please reconsider your comment as I apologize for any inconvenience.

I didn't meant to criticize you as a person, I mean, I don't even know you at all. All I was saying is that I have huge doubts that the average programmer here on the forum can write better assembly than a compiler which does optimizations.
And your post looked like "hey, I wrote the project in Assembler", at least thats what I understood from it, and this, and I hope you agree there, is really unlikely to perform better!

By no means its possible to boost performance by helping the compiler out at some parts, I do this too, for example a lot of the matrix and vector calculation done in my engine (iOS) is written in direct assembler to get the most out of NEON. I have no doubt that you can do this too, but like I said, I read your post a bit different. Sorry about that.