4 ms·
Does speed really matter? I still prefer the readable Lisp version (SBCL, no optimization): (defun square-vect (vect) (map 'vector (lambda (x) (* x x)) v
by ICWiener 13y ago
Does speed really matter?
I still prefer the readable Lisp version (SBCL, no optimization):
(defun square-vect (vect)
(map 'vector (lambda (x) (* x x)) vect))
(setq *vector*
(map 'vector (lambda (x) (random 32767))
(make-array 10000 :element-type 'integer)))
(time
(dotimes (i 1000)
(square-vect *vector*)))
Results :
0.084 seconds of real time
0.084005 seconds of total run time (0.084005 user, 0.000000 system)
100.00% CPU
218,686,836 processor cycles
79,876,912 bytes consed
On my system, the C++ version perform like this:
./main 1
1: 270756377 - elapsed time: 0.022324s
~$ ./main 2
2: 270756377 - elapsed time: 0.018883s
~$ ./main 3
3: 270756377 - elapsed time: 0.016929s
~$ ./main 4
4: 270756377 - elapsed time: 0.014268s
~$ ./main 5
5: 270756377 - elapsed time: 0.016093s
~$ ./main 6
6: 270756377 - elapsed time: 0.018651s
~$ ./main 7 # :-)
7: -1455582645 - elapsed time: 5.3e-05s
- crusso 13y agoDoes speed really matter? Yes. C++ is chosen by developers who tend to choose performance over elegance. When I was doing a lot more C++, I was intimately aware of the deep performance implications of choosing one data type and implementation technique over another.
- ICWiener 13y agoHonestly, I understand; I am really bothered too when I see people applying techniques without even thinking about performance implications (and btw, this is also true for security, correctness, portability ... implications). C++ is viewed as the ultimate language when it comes to performance, for good reasons; of course, if I ever need a fast program, I will consider it. But as an exercise, why not try to optimize the CL code, first? By using type declarations and avoiding allocating memory, here is an optimized CL version that runs under 0.01s, beating the C++ code (note that the original C++ code could be optimized too; e.g. why check the command-line argument every time?). (defpackage :test (:use :cl)) (in-package :test) (defconstant +vector+ (map '(simple-array fixnum (10000)) (lambda (x) (declare (ignorable x)) (random 32767)) (make-array 10000 :element-type 'fixnum))) (let ((result (make-array 10000 :element-type 'fixnum))) (declare (type (simple-array fixnum (10000)) result)) (flet ((square (x) (declare (optimize (speed 3) (safety 0) (debug 0)) (fixnum x)) (the fixnum (* x x)))) (defun square-vect () (declare (optimize (speed 3) (safety 0) (debug 0)) (type (simple-array fixnum (10000)) +vector+)) (loop for i from 0 to 9999 do (setf (aref result i) (square (aref +vector+ i)))) result))) (time (dotimes (i 1000) (square-vect))) Evaluation took: 0.009 seconds of real time 0.008000 seconds of total run time (0.008000 user, 0.000000 system) 88.89% CPU 22,650,364 processor cycles 0 bytes consed Evaluation took: 0.009 seconds of real time 0.008000 seconds of total run time (0.008000 user, 0.000000 system) 88.89% CPU 22,789,708 processor cycles 0 bytes consed Evaluation took: 0.009 seconds of real time 0.008001 seconds of total run time (0.008001 user, 0.000000 system) 88.89% CPU 22,418,566 processor cycles 0 bytes consed Evaluation took: 0.009 seconds of real time 0.012001 seconds of total run time (0.012001 user, 0.000000 system) 133.33% CPU 22,498,018 processor cycles 0 bytes consed EDIT: of course, now, you can say that the programs is unsafe under certain conditions; you may have an issue with the "defconstant" declaration (replacing it with a variable leads to 0.012s results). But after all, there is no specification. In practice, one must deal with actual requirements and sensible measurments.
- GFK_of_xmaspast 13y agoSpeed always matters. (Sometimes this is speed of development/iteration, sometimes this is speed of execution.)