4 ms·
I know applications may rely on API calls and may not be computational intensive. This is exactly why Python is not 100-200 slower than C, but only 3-10 times.
by mojuba 17y ago
I know applications may rely on API calls and may not be computational intensive. This is exactly why Python is not 100-200 slower than C, but only 3-10 times.
(+ a b) can be optimized in Lisp
(a + b) in C is always as optimal as it can be on a given platform. You don't put special effort to make it optimal ("oh, maybe I should declare a and b as typed... let's ask this on the forums if my compiler supports it and in what way").
- lispm 17y agowhat is a + b with two arbitrary large numbers in plain C? It can't even add correctly and implements something else than a plain addition. How can it be 'optimal'? The effect of type declaration on numeric operations is pretty much the same for all Common Lisp compilers that support that. The type declarations themselves are standardized. What is often different is the amount of type inference a compiler does. * (defun twice (a) (declare (fixnum a)) (the fixnum (+ a a))) TWICE * (disassemble 'twice) ; disassembly for TWICE ; 02AB2CBF: 488D0C12 LEA RCX, [RDX+RDX] ; C3: 488BD1 MOV RDX, RCX ; C6: 488BE5 MOV RSP, RBP ; C9: F8 CLC ; CA: 5D POP RBP ; CB: C3 RET You think this will be five times slower than C? Actually I would prefer C code to be slower and more safe by default. For that I would trade speed in a lot of places.
- mojuba 17y agoFine. Back to the original discussion, I will be left guessing why languages like Lisp and Pascal were left out, even though they may be as efficient as C. Let's say, for example, because of the lack of iPhone-specific infrastructure (APIs etc). Supporting 5 rather than 3 languages would be too much, I guess, considering the 2 are not terribly popular.
- lispm 17y agoApple is not supporting them anyway. These platforms mostly support themselves. Guess what, Lisp and others have C FFIs and Objective C bridges and can call Apple's library.