7 ms·
Modern compilers can generate very good ASM (much better than most programmers can write by hand). I think parser with similar architecture in C should be as fa
by kia 16y ago
Modern compilers can generate very good ASM (much better than most programmers can write by hand). I think parser with similar architecture in C should be as fast as written in pure ASM.
- twp 16y agoRevealing quote from the bottom of the benchmarks page: > I've performed other tests on different machines and observed that, on a Pentium 4, the difference between AsmXml and Expat is smaller (next generation processors seem to be more profitable to C programs). I also did tests with my Arch Linux but I couldn't build xerces-c so I don't publish results, but Expat was faster, may be because of 686 optimizations. Says it all, really.
- melling 16y agoCan you supply references to compilers producing faster code than assembler written by hand? I'm under the impression that the programmer can still do better, if she's willing to put in the effort.
- StavrosK 16y agoThe compiler does a million things to speed up your code, which are mostly lost when you write pure assembly. I wouldn't be surprised if a c program was noticeably faster than the same thing in assembly...
- points 16y agoYou obviously haven't single stepped through the generated assembly from any modern compiler. Sure, some of it is reasonable stuff. But the majority is utter garbage. Fire up softice and try it. Any half decent assembly programmer would beat compiled code.
- acqq 16y agoCitation needed. I actually did the above (single stepped through the generated assembly from a few modern compilers) and I haven't noticed too much of a bad code, given most of the default assumptions (i.e. to have a reasonably compatible code for different processors, to have the live entry points to the functions that are exportable etc.) Maybe you looked at the code produced with the optimizations off?
- points 16y agoI've been reverse engineering code for a living for 10 years or so, and writing assembly code for 20 or so. I don't have the time to provide examples I'm afraid, so take it or leave it ;)
- acqq 16y agoI don't buy the argument from authority, I really think you're trolling. Apart from the bad FPU code in gcc 3 (or generally relatively poor code in gcc 3 compared to more recent or more expensive compilers) I really don't know examples of significant problems in the code generation of modern C compilers. Just don't give me examples that work only on the latest CPU's or that are fast only on one of CPU generations or on the CPU of only one manufacturer.
- scott_s 16y agoIt's worth it to go through the slides from this talk by Felix von Leitner on Source Code Optimization: http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf http://www.linux-kongress.org/2009/slides/compiler_survey_fe... If you're writing an entire application in assembly for fun, then, sure, have at it. But if you're writing an entire application in assembly because you want better performance, then I think you're misguided. Write it in C, turn all optimizations on, run it with a bunch of benchmarks, profile it. Look to see where the bottlenecks are. Optimize those, maybe in assembly, or maybe by just being smarter with your C code.
- DrJokepu 16y agoWell, compiles these days can do incredibly crazy tricks to squeeze out every bit of performance. That being said, if a human knows these tricks as well, he can probably apply them even better than a compiler.
- gaius 16y agoFrom the FAQ: Assembly is fun. Do you really think I would have written a parser in assembly in my spare time otherwise.
- frou_dh 16y agoHow good a job "most programmers" could do in general doesn't matter. What does is the programmer of the concrete software in question.