lovely discourse, but although I feel bad disagreeing (on a tiny point) with the otherwise very agreeable Mr. Cote...
On 8/27/08, Dennis Cote <[EMAIL PROTECTED]> wrote: > Derek Developer wrote: > > Thanks for the link. Unfortunatly its a little expensive and probably > > 50% slower than my implementation. > > > > > On what basis do you make that claim? > > > > No offense, but C is a language that a lot of us tolerate and is not > > the panacea that some C developers like to believe it is. Reading C > > is like reading Chinese. ASM may not be a high level language, but it > > certainly is fast. > > > > > C is the lingua franca of the computer world. Every programmer should be > able to read it comfortably. I find reading well written C code, such as > SQLite, to be pleasant, and certainly much easier than assembler code. > Some languages, such as APL (which I liked) and Perl (which I really > don't know very well) are inscrutable to the casual reader. only badly written Perl, or Perl specifically written to be obfuscated such as in Perl golf, is inscrutable. Well written Perl (I practice as close to literal programming in Perl as possible) is quite pleasant and easy to read. Other than that, yes, agree with everything else you say. > C is not and > should not be in that category. > > Assembly language has two major drawbacks, it is not portable and it is > very verbose. The first means that any code you write for one platform > has to be completely rewritten for another. The second often leads users > to adopt the shortest, simplest, code sequence to accomplish their goal. > This is often not the fastest way to accomplish that task. Usually, > selecting a better algorithm will do far more to speed up code than > rewriting it in assembler. > > Studies have consistently shown that a good compiler can produce code > that is nearly as good as the best hand crafted assembly. There is > almost never a reason to write anything except the core inner loops of a > CPU intensive operation (such as encryption or decryption) in assembler. > It is quite simply a waste of time to do otherwise. > > The only effective way to write assembly code is in conjunction with > good measurement tools. Write the code in a high level language with a > good optimizing compiler, like C. Then measure the code to determine > where the program actually spends its time. Next, review the code > generated by the compiler for the inner most loops in those sections, > and replace with hand written assembly code only if you believe your > assembly code will be faster than that produced by the compiler. > Finally, measure the resulting code and see if it is in fact any faster > than the code the compiler generated. > > In this day of out of order and speculative execution of instructions, > and the critical dependency of the CPU on the performance of the memory > caching system, it is very difficult to guesstimate the execution speed > of a sequence of code especially assembly code. Modern compilers often > do a much better job of this than any developer can. > > Assembly can be used to write faster code snippets, but it is often > slower when used to write large applications because the difficulty in > writing higher level, more complex, algorithms in assembler often leads > to the use of simpler slower algorithms. > > In short, writing in assembly language does not guarantee that the > resulting program will be fast. Assembler can be fast, but it is by no > means certain that it is fast. > > > Dennis Cote > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Puneet Kishor http://punkish.eidesis.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
