Timeline for Implementing numerical integration
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 27, 2018 at 4:59 | comment | added | Craig Estey |
For the largest gammath, the pdf_cache max size is about 1M elements. At 4 bytes / entry, this about 4MB. This fits within the cache memory of most x86 CPUs, so most access to it will come from the faster cache memory rather than the slower DRAM. On each loop, the pdf_cache element fetch is faster than recalc of pdf (i.e. it eliminates a floating point add, multiply, and divide on each iteration).
|
|
| Jul 27, 2018 at 4:39 | comment | added | Craig Estey |
This is compiled in c++ [a superset of c] and at a lower level they overlap and are compatible [arguably]. I just added the malloc/printf [which works in c++ but is more idiomatic in c] (e.g. it's not the "pythonic" way but it works :-). Otherwise, all the other code here is interchangeable. And, the bulk of your code, integ, cdf, pdf are c/c++ agnostic. So, as above, the final benchmark is 2.75x faster than your original [where all I did was add benchmarking code] on a single core. My final version can be combined with the multicore stuff of others to get the best of both
|
|
| Jul 27, 2018 at 4:10 | comment | added | BlackMath |
Interesting observations. I am not familiar with C, but do you have a rough total speed up factor compared to the original? du=0.01 should run fast, but will give some insights.
|
|
| Jul 27, 2018 at 3:06 | history | edited | Craig Estey | CC BY-SA 4.0 |
added more explanation
|
| Jul 27, 2018 at 2:54 | history | edited | Craig Estey | CC BY-SA 4.0 |
added more explanation
|
| Jul 27, 2018 at 2:33 | history | edited | Craig Estey | CC BY-SA 4.0 |
added more explanation
|
| Jul 27, 2018 at 2:26 | history | answered | Craig Estey | CC BY-SA 4.0 |