2 ms·
The "fade", "grad" and the "lerp" are written as member functions (so there is some "this" pushing), yet there is no need for so. There might be some speedup (o
by malkia 14y ago
The "fade", "grad" and the "lerp" are written as member functions (so there is some "this" pushing), yet there is no need for so. There might be some speedup (overall) inlining them.
The author claimed it's straight JAVA translation from Ken Perlin's code, yet he managed to drop the "static" for the above three functions.
EDIT: Some more problems.
Since perlin noise is perfect candidate for data-parallel split, it would much more efficient to split the job where instead of creating one image / thread, you split one image among all threads and process them individually.
This way memory usage is reduced - e.g. you are processing one image, not N. For very big images it might be even more efficient to limit processing of one thread to a 16x16 or 256x1 image blocks.
There is another Java->C++ problem with the code in this case - since you instantiate the p[] array (not static again), this means that each worker would have it's own array, hence wasting L1 cache (the p[] data is all the same).
Overall this task is more suited for OpenMP (data-parallel), than the async stuff (but thanks for demonstrating it, I was not familiar)
- minimax 14y agoIt looks to me like the lowest hanging fruit in terms of reducing the program's run time is in the PPM output code. https://github.com/sol-prog/async_tutorial/blob/master/ppm.cpp#L104 https://github.com/sol-prog/async_tutorial/blob/master/ppm.c... Three calls to ostream::write() for each and every pixel. oof.