Agreed. But you should have understood MM, pointers, and stacks if you're working on some business application.kataklinger wrote: I don't want to think about MM, pointers, stack... if I'm working on some business application or something like that.
)... But on the first year of studies there's a C as well as Java, but there's no C++ later on at all (???).
Mabye they learned C or ASM first? Mabye they didnt?@Solar: Text is good. I would agree with that guy on most parts, altought I know some very good pure Java & C# programmers
Nope, this ones fine. More people might see my link, and mabye I can go to sleep knowing someone found it useful.Shouldn't the languages discussion be in its own thread? The only thread I've seen recently that has stayed on topic is the Processor Design one, lol.
Knowing assembly helps to (re)write C-code which generates faster code. This can be done by doing an 'objdump' of a compiled piece of C-code for example. If you then also study how C-compilers work then you can even further optimised or better code. But when knowing all the ASM and compiler stuff the better/faster C-code comes automatically.If someone likes ASM vs C, thats great. It helps to know ASM, when working with C. I don't know how much. Thats takes scientific evidence - statistics - math. All that matters is the same thing that matters to a company:
Code: Select all
int main() {
float matrix[10000][10000];
printf("running");
}
Basically true, as long as you keep in mind that:RetainSoft wrote: @kmcguireKnowing assembly helps to (re)write C-code which generates faster code. This can be done by doing an 'objdump' of a compiled piece of C-code for example. If you then also study how C-compilers work then you can even further optimised or better code.If someone likes ASM vs C, thats great. It helps to know ASM, when working with C. I don't know how much. Thats takes scientific evidence - statistics - math.
It is much more. You claimed that C programmers are inferor to all others. I provided a link that says that knowledge and skill in C, while not making you somehow superior to your peers, does teach you a thing or two about programming. Java types should know about pointers. Assembler types should know about structured programming and modularization. Both can be learned elsewhere or without ever touching a different language, but most of the time it isn't. And the guys can still code Java and Assembler for all I'm concerned, but they should know (or, quite honestly, hope they never work in my team).This is a typical example of, Do as i say, not as i do.
You have posted to a link, that is nothing more than a, "if you do not code in C you must be some how inferior" .
I tried to optimize a bit of mmx code I wrote with some prefetch statements that I didn't add before. Out of the dozens of tests I did, around 5 were faster than the original. A few ended up slower than the non-MMX code the compiler created out of similar C code and a few gave an improvement of around 10%, up to 20% for the best one. Yes, that's an improvement. Yes, if that's in your critical path, you'll speed up the program by 25%. And yes, if it isn't, you won't notice and spend hours on it without speedup.1) Today's compiler backends are usually much better at keeping modern CPU pipelines fed than you are, so don't try to outsmart the compiler backend with hand-"optimized" assembler - that will turn out to be actually slower in the majority of cases.
Not entirely. That was the speedup from my start code without prefetches to my fastest code, which was about 4x as fast as the gcc code.Solar wrote: Sounds like about as much speedup as by using the Intel compiler instead of GCC. ;D
Well... performance squeezing is a little more impossible nowadays, there are just too many bits to optimize. Given a program or function with a few critical paths that slow it all down, it's pretty damn the same. Messing with a few cycles or subcycles of difference to get that last bit of speed.Agreed, the vector-unit backends are still playing catch-up. But when you tinkered with MMX, you'll agree that squeezing extra performance out of a modern opcode set is a far cry from what we did on a 6502 or 68000...
