Nicely put Greg. Building, debugging, benchmarking, and profiling data structures is a great exercise which teaches many skills. Placing emphasis on the debugging, benchmarking, and profiling will develop really useful tools of the trade. The data structures are a great vehicle for that. Discussing what is discovered at each stage really helps build understanding, as you nicely point out in the what has "changed" between computers point.
Martin... On Thu, 18 Oct 2018 at 18:01, Greg Young <[email protected]> wrote: > So I would probably focus on some more basic principles with them and > focus on what is faster and *why*. I would also *NOT* use javascript if the > point was to look at efficiency but instead something like C. To be fair > you can teach an aspiring student enough C to write basic data structures > very quickly if they already know javascript. > > When learning basic data structures and algorithms as an example learning > sympathy with them is *required* for really understanding them. Let me give > an example, a linked list or unbalanced tree made up of malloc'ed nodes vs > a linked list made up of nodes pre-malloced into an array. How does each > perform? What are the trade offs? What happens when the array is filled? If > just malloced what happens when we introduce *other* mallocs into our code > as it runs? Even such a simple implementation which is < 200 loc can go a > long way towards understanding some trade offs involved. Looking using a > tool at things like cache misses can also show *why* things may be doing > what they are doing (eg when array gets too big to fit in cache and you > suddenly see a slowdown due to the misses!) > > You can get pretty deep into what the computer is actually doing *very* > quickly in such an example. I might also take the example to show the same > code in assembler (as output by the JIT or compiler), most compilers can > output, or you can view assembler from higher level languages such as > java/C# (how to view asm from java/C# is also a useful skill few java/C# > devs even KNOW (most professional devs don't know how to do this!)). > > Doing such you can very quickly get into things like how memory locations, > caching, and other thing cause differences in how code executes. Another > obviously fun one here is to look at the JIT compiler in debug/poduction > mode, what optimizations were applied, how things are laid out, etc. > > One thing to be careful about here is that each student's computer will > have slightly different behaviour. As such the parameters where things > "change" will be different. A great board exercise would be showing each > students computer, where things "changed" and comparing it to their > processor/memory specifications/etc to see if patterns can be found. > > As a side note when dealing with mechanical sympathy I would almost > *never* use javascript you will be learning far more about javascript and > how to *force* it to do things (and getting tons of false positives to weed > through) than learning about underlying things. > > HTH, > > Greg > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
