00:21 | fredy330 | left the channel | |
00:55 | fredy330 | joined the channel | |
00:55 | danieel | vup: the vectorized code is better than a hand crafted sse/avx inline?
| |
00:57 | vup | danieel: well I did not try hand crafted sse / avx, but if you look at the generated code: https://rust.godbolt.org/z/aYKnv8Y5e
| |
00:57 | vup | its actually super clean
| |
00:57 | vup | and probably very similar to what I would come up with
| |
00:59 | danieel | thats nice... can we try if it can do Neon? (like on arm?)
| |
01:05 | vup | danieel: yeah it looks like the neon code is super clean aswell: https://rust.godbolt.org/z/64q96aenP
| |
01:06 | vup | (even nicer than the avx2 code, but that is expected, as sse/avx does not have a lot of instructions for 8 bit integers, for example shifts are missing, so you first need to convert the 8 bit integers to 16 bit integers)
| |
01:07 | danieel | is that just what rust gives? or llvm/gcc can do as well?
| |
01:07 | danieel | if this can do both.. then no need to use inline asm :)
| |
01:09 | vup | I mean that is what rust gives, but as is uses llvm as backend I would expect similar results for c
| |
01:09 | vup | and indeed: https://godbolt.org/z/z8zGsndz3
| |
01:10 | vup | the naive c translation produces pretty much the exact same code
| |
01:10 | vup | (works for sse/avx aswell)
| |
01:11 | vup | gcc produces a more complicated, but still vectorized and atleast for sse/avx similarly performing version
| |
01:11 | vup | (did not benchmark the neon version myself yet)
| |
01:12 | danieel | well, i am amazed
| |
01:12 | vup | In general, I would expect the vectorization for c/c++ to be a lot better even than the one for rust, because rust for example has bounds checking for array accesses, which it first has to figure out how to optimize away
| |
01:14 | vup | (otoh rust disallows aliasing of mutable references, so thats one point where its simpler for vectorization, but in c you can of course always use `restrict` to help the compiler)
| |
02:03 | Bertl_oO | would be nice to see if 'readable' C code can outperorm the neon remapper ;)
| |
02:03 | Bertl_oO | *outperform
| |
05:14 | Bertl_oO | off to bed now ... have a good one everyone!
| |
05:14 | Bertl_oO | changed nick to: Bertl_zZ
| |
06:51 | se6astian | good day
| |
06:52 | se6astian | vup: bandwidth.bmp uploaded to https://cloud.apertus.org/index.php/s/NsbF5kD4Yt4SpZg
| |
07:39 | se6astian | have you seen https://libre-soc.org ?
| |
10:02 | se6astian | https://wiki.apertus.org/index.php/Raw12_viewer documentation created and https://wiki.apertus.org/index.php/RAW12 updated
| |
11:51 | Bertl_zZ | changed nick to: Bertl
| |
11:51 | Bertl | morning folks!
| |
14:10 | Bertl | off for now ... bbl
| |
14:11 | Bertl | changed nick to: Bertl_oO
| |
14:50 | se6astian | vup/anuejn/Bertl_oO: Do you know why black coloumns feature seems to be commented out in current snap code: https://github.com/apertus-open-source-cinema/axiom-firmware/blob/main/software/sensor_tools/snap/snap.c#L620 ?
| |
14:59 | se6astian | seems like it was that way from the beginning? a mistake we never noticed?
| |
15:09 | se6astian | pushed fixed
| |
15:09 | se6astian | https://github.com/apertus-open-source-cinema/axiom-firmware/commit/9eed0c6943af4b007a207f6aefc94e35af57eef1
| |
15:09 | se6astian | tested on beta
| |
15:09 | se6astian | seems to be working fine
| |
16:06 | vup | yeah libre-soc has been around for some time
| |
16:08 | vup | not sure about the black column feature
| |
16:25 | vup | Bertl_oO: so this seems to get auto-vectorized: https://paste.niemo.de/raw/ixomuboteq
| |
16:25 | vup | but one would have to benchmark it against your handrolled version
| |
16:34 | vup | also did you every try just mmaping the file instead of converting line by line and then copying that to the file?
| |
17:02 | Bertl_oO | the main idea for the conversion is to use it as a 'filter' in a pipeline, so mmaping is not suitable for this purpose
| |
17:03 | Bertl_oO | regardings benchmarking: yes, that would be nice to see, se6astian ^^
| |
17:09 | vup | Bertl_oO: hmm what more filters do you envision in the pipeline for snap?
| |
17:28 | illwieckz | left the channel | |
18:09 | Bertl_oO | not necessarily for snap, the idea here was to use memtool to read/write data from/to memory and to convert it on the fly
| |
18:21 | vup | right
| |
19:35 | balrog | left the channel | |
19:39 | balrog | joined the channel | |
20:12 | illwieckz | joined the channel | |
22:34 | fredy330 | left the channel |