freenode/#sicl - IRC Chatlog
Search
19:37:11
shka_
i spend so much time on this damn shuffle that i was very surprised when i turned out that merge works correctly with first attempt
19:46:37
jcowan
anyway, I have two new concerns: I think 8-bit and indeed 16-bit subtypes of string are indeed important, since a huge fraction of all text is within the Latin-1 repertoire and almost all of it is in the Plane 0 repertoire
19:48:55
jcowan
second, I find the idea of 27-bit single-floats on 32-bit platforms to be a bad one, for two reasons: (a) rounding from a 32-bit computed result to a 27-bit stored one will have to be performed carefully and without hardware assist;
19:49:19
jcowan
(b) I think it will be very surprising that arithmetic on arguments obtained from specialized float32 arrays (which are mentioned in th array chapter) will be done only to 27-bit precision.
0:33:50
fiddlerwoaroof
beach, scymtym: on #slime, there's some talk about using eclector as a backend for some slime features
0:47:07
luis
At this point, I'm wondering if it makes sense to grab user-defined reader macros from cl:*readtable* into the Eclector readtable to be able to play with code that uses such reader macros or if there's a better strategy. (E.g., do it the other way around and inject bits of Eclector into cl:*readtable*)
0:50:09
luis
Also, is there a code walker that takes CSTs as input? It doesn't seem too hard to adapt an existing code walker to use CSTs, but I guess I'm fishing for code walker recommendations as well.
3:46:40
beach
jcowan: I removed any mention of 32-bit platforms for floats, and I removed the suggested non-IEEE formats. I have yet to decide about strings.
3:49:07
beach
luis: The "code walker" I am thinking of for Second Climacs is Cleavir. It takes a CST and converts it to an AST, using a first-class global environment. I am thinking of making an incremental implementation of the first-class global environment protocol so that it would be possible to restart the parser after any top-level form in a file/buffer.
4:50:28
jcowan
beach: you might also want to consider providing IEEE 16-bit floats as short-floats, as there is now some hardware support for them on x86_64 (specifically an instruction that properly rounds a 16-bit float to a 32-bit float). Every float16 value has an exact float32 counterpart.
4:59:41
no-defun-allowed
yeah, there's a lot of research into how many bits evaluation and training of neural networks requires
5:00:22
|3b|
interesting light values range from candle to direct sun, but don't need much precision for the direct sun case
5:01:32
no-defun-allowed
i don't believe there's hardware support except for custom logic, but 8bits is the hip in NNs now
5:02:54
beach
Y'all seem to know a lot. Do you happen to know whether there is an x86 instruction for multiplying two complex double floats?
5:04:15
no-defun-allowed
https://stackoverflow.com/questions/10329903/efficient-complex-arithmetic-in-x86-assembly
5:04:50
jcowan
this page looks relevant: https://stackoverflow.com/questions/10329903/efficient-complex-arithmetic-in-x86-assembly
5:05:00
no-defun-allowed
admittedly, i don't know much complex arithmetic besides the output of bordeaux-fft so i can't really comment on that
5:06:38
|3b|
though possibly not worth it for doubles depending on brand and price of the GPU, since that is a 'pro' feature on some brands :(
5:09:19
|3b|
oddly 16bit float is a 'pro' feature too, since NN like them, so might not be faster than single :/
5:11:38
|3b|
yeah, if latency isn't an issue, you can probably do a lot of sound processing on a GPU :)
5:13:22
beach
I am not planning to use this information any time soon, but it changes how I think about some of my very low-priority projects.
5:14:34
|3b|
GPU are optimized for working on large chunks of data at once, so you tend to want to work on longer segments, and you also have latency for transferring to/from GPU memory, and for going through the API
5:14:42
beach
Another thing that has changed the game is multi-core processors. Producing sound is a highly parallel procedure.
5:15:11
|3b|
yeah, CPU are pretty decent at that sort of thing too, especially if you can use their SIMD features
5:18:22
|3b|
(and just to be clear, when i mentioned latency i mean from starting processing to getting results, so delay when processing a live stream or playing live... once you start though, you should be able to produce a continuous stream without gaps assuming it runs in realtime to start with)
5:20:36
|3b|
so good for offline generation/processing of sound, or realtime generation/processing if an initial delay is OK
5:21:16
|3b|
for other cases, might be OK, but i'd suggest to do some tests before investing a bunch of effort into it :)
5:22:38
|3b|
(graphics, particularly VR, is doing latencies in the 10s of ms range or less, but doesn't have to copy back to CPU to send to another API for output, or at worst goes through some optimiized path in drivers)
5:24:44
|3b|
yeah, probably could get into the few ms range, but i'm not sure exactly without actually trying it
5:25:33
beach
Like I said, I am not going to do anything about this soon, but I'll keep these things in mind when contemplating future work.
5:25:37
|3b|
and also depends on the amount of work, have to be doing a lot of work per sample for a few ms of sound to be a good fiit for GPU