freenode/#lisp - IRC Chatlog
Search
4:51:59
aeth
Bike: Should I move my length 16 array to a (4 4) array for my 4x4 matrices? You seem to know more about this than anyone else in the previous conversation.
4:52:26
aeth
It does look like SBCL can declare them dynamic extent, so they do seem to be useful enough for my uses.
4:53:48
aeth
It looks like dynamic extent still works with (list (list ...) (list ...) (list ...) (list ...)) for the initial contents (which I assume an inline make-matrix-4x4 would produce)
5:11:08
aeth
In the length 16 version it's all MOVSS, MULSS, and ADDSS. In the dimension (4 4) version, it has a lot of MOV instructions added
5:12:11
beach
borei: I suggest you introduce a variable using LET that you sum into. That way, you can declare the type of it.
5:12:47
beach
borei: It is complaining that when you use the SUM LOOP keyword, the type of the implicit variable it sums into is not known to be DOUBLE-FLOAT.
5:14:50
aeth
Bike: It's probably slightly slower, but it's really hard to tell because my computer is too fast and any loop will optimize it away
5:14:53
beach
borei: Well, you have the LOOP keyword DO at the end of the line instead of at the beginning.
5:19:24
beach
borei: You can "play with" the variables first, but you should work on the code layout before resubmitting.
5:39:26
borei
single-threaded application on the consumer-grade CPU with performance a bit less then 1Gflop on double precision numbers
5:41:28
aeth
Lisp isn't slow, but it doesn't have as many optimizations as a more popular AOT compiled language. Mainly becaue it doesn't have as many humans optimizing it as a more popular AOT compiled language.
5:41:46
aeth
But I suspect a lot of those optimizations are pointless when you're just doing linear algebra.
5:45:29
borei
i got additional and huge motivation for big dive into LISP ecosystem, huge thanks for support !
5:46:45
fiddlerwoaroof_
borei: if you're doing matrixy-stuff and have an Nvidia GPU, you might look into Gabor Melis's libraries, like mgl-mat
5:47:21
fiddlerwoaroof_
I've never got them to work because I don't have the hardware, but they look really nice for machine-learning applications
5:47:25
aeth
k-hos: Well, I think Lisp games would benefit the most from a concurrent, parallel, real-time garbage collector.
5:49:16
borei
fiddlerwoaroof_: actually i have question about ML, can you recommend any materials about ML+Lisp to read (entry level)
5:49:16
aeth
fiddlerwoaroof_: The most important part in the GC buzzwords for games is real time, afaik.
5:49:39
fiddlerwoaroof_
aeth: The built-in java GCs are really advanced, because of the JVM's position in the industry
5:49:48
aeth
Games are usually on some strict schedule (or two, if the rendering framerate is separate from the logic one). e.g. 0.01 second ticks or something.
5:51:52
fiddlerwoaroof_
borei: CL isn't the best yet for modern ML, just because we don't have the libraries that python/scala have. However, Gabor Melis managed to do pretty well using his own libraries
5:57:59
aeth
k-hos: Most games wind up using a garbage collected scripting language in addition to a non-garbage collected engine language.
5:59:33
fiddlerwoaroof_
Hmm, it looks like redhat has recently opensourced a low-latency GC: https://wiki.openjdk.java.net/display/shenandoah/Main
6:00:09
k-hos
personally I would prefer no gc and have some kind of ref counting mechanism built into the language
6:03:54
k-hos
it's pauses and inconsistency that make gcs generally bad for games, but there is little point to arguing about a theoretical language anyway
6:04:18
beach
k-hos: There are very good real-time, parallel, concurrent garbage collectors these days.
6:11:09
aeth
jackdaniel: Yes, because I think there are literally dozens of people on IRC who want one.
6:26:42
aeth
It does look like the (16) array is consistently around 2.8 kilocycles compared to the (4 4) being consistently around 3.8 kilocycles. So that is quite a drop in performance, even though I have to use SBCL's cycles to even notice it at all (0.000 seconds)
6:27:20
aeth
I've played with different ways of expressing it, e.g. pulling out all of the array accesses into variables first
6:29:00
aeth
Maybe the next thing I could try is using a loop instead of doing all of the adds/multiplies,
6:38:35
aeth
It looks like the 4x4 matrix is always slower than the fake 4x4 matrix because SBCL can't access items from it as well. It generates an extra MOV for every one or two MOVSS, which adds up a lot in matrix multiplication. Both on retrieving the values and on setting the destination matrix.
12:43:26
drmeister
Is there a way to shut down pretty printing for trace output? Or is this an implementation dependent detail?
12:44:35
Shinmera
Well, setting *print-pretty* is an option unless the implementation changes that itself during tracing.
12:48:23
scymtym
maybe implementations could add something along the lines of SB-EXT:*DEBUG-PRINT-VARIABLE-ALIST* for TRACE
12:48:58
drmeister
Sometimes in clasp trace generates pretty printed output and other times it doesn't.
12:49:27
drmeister
It's pretty much "(setq *print-pretty* <which one doesn't drmeister want right now>)"
13:01:16
drmeister
(blush) Simply (setf *print-pretty* nil) in the slime repl turns pretty printing off for trace