Custom Query (1030 matches)
Results (940 - 942 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #1128 | fixed | Specialized arrays for complex numbers | ||
| Description |
I want to use CCL for signal processing and I'm using bordeaux-fft. However, this is quite slow and conses a lot, presumably because CCL lacks specialized arrays for complex numbers (single-float and double-float), in contrast to, e.g., SBCL (upgraded-array-element-type '(complex double-float)) ==> T seems to attest this assumption. So I ask you to add specialized arrays of (complex single-float) and (complex double-float) |
|||
| #1192 | fixed | Bordeaux FFT problem | ||
| Description |
Are specialized arrays for complex numbers supposed to work, yet? I tried loading bordeaux-fft on an Odroid U3 (linuxarm) and got this: Welcome to Clozure Common Lisp Version 1.10-dev-r16104-trunk (LinuxARM32)! ? (ql:quickload "bordeaux-fft") To load "bordeaux-fft":
; Loading "bordeaux-fft" [package bordeaux-fft]
The backtrace is attached. |
|||
| #1199 | wontfix | Possible wrong memory alloc statistics on multicore | ||
| Description |
I did some quick performance tests using the :lparallel library by replacing dotimes/mapcar by pdotimes/pmapcar in some raytracing programs. The results were correct and the speed-up on a quadcore Ubuntu Odroid U3 were plausible (about 2.5 times), however, the amount of memory allocated reported by the time macro was about 100-300 times LESS than the single thread original version. Perhaps only the memory allocated by the parent thread is counted in the statistics? |
|||
