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