Mercurial > repos > public > sbplib_julia
comparison Notes.md @ 750:f88b2117dc69 feature/laplace_opset
Merge in default
author | Vidar Stiernström <vidar.stiernstrom@it.uu.se> |
---|---|
date | Fri, 19 Mar 2021 16:52:53 +0100 |
parents | 3cd582257072 05d8ea88c690 |
children | 1784b1c0af3e |
comparison
equal
deleted
inserted
replaced
723:c16abc564b82 | 750:f88b2117dc69 |
---|---|
310 Implementation of this is an issue that requires some thought. Adding an extra | 310 Implementation of this is an issue that requires some thought. Adding an extra |
311 "Embedded" type for each grid would make it easy to understand each type but | 311 "Embedded" type for each grid would make it easy to understand each type but |
312 contribute to "type bloat". On the other hand adapting existing types to | 312 contribute to "type bloat". On the other hand adapting existing types to |
313 handle embeddedness would complicate the now very simple grid types. Are there | 313 handle embeddedness would complicate the now very simple grid types. Are there |
314 other ways of doing the implentation? | 314 other ways of doing the implentation? |
315 | |
316 ## Performance measuring | |
317 We should be measuring performance early. How does our effective cpu and memory bandwidth utilization compare to peak performance? | |
318 | |
319 We should make these test simple to run for any solver. | |
320 | |
321 See [this talk](https://www.youtube.com/watch?v=vPsfZUqI4_0) for some simple ideas for defining effecive memory usage and some comparison with peak performance. | |
322 | |
323 |