Scribit Mac Chan dies 04/05/2007 hora 11:11:
But I find it funny that you repeatedly say that there _will_ be a cache miss using the debug-value macro. How do you know? Maybe you meant _potential_?
Yeah, that was incorrect, that's only a possible cache miss.
I think it's incredibly painful to consider that scenario when one is writing lisp code.
Well, you typically only have to worry about cache misses in the critical path of some part of a system whose performance affect it as a whole, like IPC in a µ-kernel or request handling in a network server, it seems.
Have you done any loop unrolling in lisp?
Not really. I only studied loop unrolling as I was a C++ programmer, and C++ make it a pain, because you need black magic. Now that I begin to understand Lisp's macros, I barely begin to imagine I could do easy and efficient loop unrolling sometimes...
Do you declare all the types in your code? I think most people come to lisp for fast prototyping and implementation correctness. Lisp by default is fast enough for most things.
The critical path of my applications so far was always in underlying libraries, like Hunchentoot or Elephant, so I never had the need to profile and optimize my own code.
In fact I need to eval (setf-leaked-variables *leak*) everytime I change something with the browser. That would take away all of fun, wouldn't you agree?
No, because it happened quite some times that I have to debug some part of an application under stress, and then having the various debugging variables rebound by each request would have been unacceptable.
If some people find this *debug-mode* really useful, though, it shouldn't be that hard to write the switch not as a dynamic variable (used much as a global variable, in this case) but as a function that changes the various functions of Hunchentoot where the variables are bound. When in a non-debug mode, it would store the debugging alternatives, and in debug mode, it would store back the current ones...
Curiously, Pierre