comparison Notes.md @ 718:05d8ea88c690

Add note about performance testin
author Jonatan Werpers <jonatan@werpers.com>
date Fri, 12 Mar 2021 19:55:39 +0100
parents 841ca12f3359
children f88b2117dc69 d7d030f8f708
comparison
equal deleted inserted replaced
701:38f9894279cd 718:05d8ea88c690
309 Implementation of this is an issue that requires some thought. Adding an extra 309 Implementation of this is an issue that requires some thought. Adding an extra
310 "Embedded" type for each grid would make it easy to understand each type but 310 "Embedded" type for each grid would make it easy to understand each type but
311 contribute to "type bloat". On the other hand adapting existing types to 311 contribute to "type bloat". On the other hand adapting existing types to
312 handle embeddedness would complicate the now very simple grid types. Are there 312 handle embeddedness would complicate the now very simple grid types. Are there
313 other ways of doing the implentation? 313 other ways of doing the implentation?
314
315 ## Performance measuring
316 We should be measuring performance early. How does our effective cpu and memory bandwidth utilization compare to peak performance?
317
318 We should make these test simple to run for any solver.
319
320 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.
321
322