Laser pointer, a learning guru, and I'm ready to start class. All right, so welcome back to class. It's Wednesday, last full week of class. Today, we're going to try to get through performance so that we can talk about virtualization on Fridays. I think it would be sad if we didn't do any virtualization. I might move a little quickly today. But yeah, so our goal is to talk about benchmarking and then get through a really important computer science concept, which I actually think is applicable to everyday modern life as well, which is called Amdahl's Law. How many people are familiar with Amdahl's Law? A couple of you, OK. How many people ever remember hearing Ross Perot say that if you have one penny and someone gives you another penny, then you've doubled your net worth. But you still only have two pennies. I think that's a variant of Amdahl's Law in some way. So we'll talk about maybe some colloquial ways to apply Amdahl's Law. All right, so the exam is a week from Monday. At 8 AM, here, I think it's here in this room. So stuff's on the calendar. The format will be similar to the interim. And we have an all-release last year's exam for people to look at. So last year, unfortunately, in the hackathon, we did not have a winner from this class. So that offer to release an exam question early did not play out for you guys. However, at least last year, there was some sort of have you guys got any sort of feedback form regarding this class? Oh, OK, so they haven't sort of bothered me about that yet. But last year, I think we had an agreement where I need to look at what the numbers are. But if we get a certain percentage of feedback from the class, then I will release one of the exam questions early. So I'll email out, we'll decide what that threshold is. Actually, I think last year, I didn't offer to release two of them early, but they didn't quite make it to that threshold. They did make that threshold after the exam. At that point, it's like, why bother? But so yeah, I'll send out something on Piazza about that. And then next Monday, so we did this last year, and it was kind of fun in a sort of masochistic way. But we'll do exam review next Monday at 8 AM from 8 to 10. So normal class time plus the extra hour from 8 to 9. You can think of this as like practice waking up on time for the exam. And we have a little bit to talk about. So anyway, I'll bring coffee and donuts next Monday. And we'll have fun. We'll just go over some of the material, maybe go through the last year's exam. And all this is on the Google account. OK, so questions about sort of, we didn't actually talk about benchmarking out, but questions about the performance analysis stuff that we had talked about on Monday. OK, so who remembers? I mean, what other than everything was hard about this so far? What were some of the challenges that we had encountered once we started to think about how to improve the performance of our system? What was one of them, Satish? Yeah, so measuring the system at all. We talked about just even getting timing information from the system wasn't easy. What else? What else was another challenge? Yeah, I mean, you have so many choices. You could just say anything that's involved. So yeah, picking what to measure. What is the actual yardstick that we're going to use? And then what is something else that we were concerned about? When we start talking about benchmarking, Robert, what are we really talking about in terms of system performance? We're going to measure something. That's going to mean we can measure it. We're going to measure it. We're going to measure something. But then we also have to determine what else. Tim? Yeah, kind of. I mean, what we really need to do is figure out what is the system going to be doing? What tasks are we going to give it to do? So is this going to be, are we going to measure it doing like 100-yard dash, or are we going to measure running a mile? So we need to figure out what the benchmarks are. So we had this approach of measuring the system, but how are we going to collect those measurements, that wasn't necessarily straightforward. And then what is the system going to be doing while we do that? We'll start to get into this a little bit today, but this gets to be into a part that maybe at least computer scientists, I don't know, computer engineers, statistics, no problem. But keep your scientists are kind of like, eh. And then this is probably the most important thing we're talking about today is in terms of once you've identified the slow parts of your system, or once you're able to start to profile the system, to examine the relative performance of each component, how do you decide what to work? We talked about pros and cons of models and simulations, so models allow us to make these strong guarantees about system performance. But they usually end up, in order to prove things about the system, in order to model it mathematically, we usually end up having to make a lot of really unrealistic assumptions. Simulators, on the other hand, if they're well-designed, can offer us a significant speed up, maybe. So Guru's been doing some work on an architectural simulator that does not offer any significant speed up. In fact, it's an order of three orders of magnitude, at least slower than a real system. So there, what we're getting out of it is flexibility, or we're giving up is speed, because it's way slower than hardware. But in the best case, you can build a system that abstracts way enough details that improves performance and allows you to run more repeatable experiments. But in the worst case, you end up losing some important features of the real system along the way, and that makes the results not really that useful. All right, so. And then we talked about different metrics we might use to compare different parts of the system. And in a lot of these cases, we've talked about this over and over this semester. I mean, there's a lot of interesting design decisions that get made when we design operating systems. And also, when you design hardware components, and a lot of those design decisions involve trade-offs between one thing and another thing, both of which are desirable. So who can give me an example of a case where the design of an operating system component might involve a trade-off between two desirable properties of the system? Spencer. Yeah, that's a great example. So how much memory do I allocate to the buffer cache, which is going to improve file system performance, versus how much memory do I allocate to process address spaces? So that is a nice example. What's another one? Wembley. What about in scheduling? What were some of the things we wanted from schedulers? And how were they in what's that? Types of parents that get scheduled options. Well, what were some of our goals for scheduling? Who remembers? Peng, what was one of them? What's that? Yeah, so we were concerned with throughput. Like, we really care how much work the system gets done. But what does throughput frequently come into conflict with? Andrew. Yeah, interactivity. Interactivity requires a switching back and forth between things to maintain this illusion of concurrency. But every time we do one of those switches, we're sacrificing some throughput, because we're spending the time and energy to reconfigure the system for a new threat. So that's another case. And there's several others. Most of the things we've talked about this semester are involved in some trade-off like this. Yeah, Jeremy. Correctness for holding B? Yeah, so there's another good one with modern operating systems, correctness. I would like the system to not fail. And so what was one example of that from our discussion of operating system architecture? What was an architecture example that tried to achieve correctness potentially or stability potentially at the price of speed? Yeah, Paul. What's that? OK, so Dijkstra system, yeah, for sure. But what's a more modern design alternative that tried to do this? Greg, you remember? That's not what I'm thinking of. Yeah, the microkernels, right? Microkernel's idea was if I reduce the amount that's inside the privileged kernel address space that runs with kernel privilege, this system is going to more likely be more stable. The less code I have that can crash the system, the less likely this is going to crash, hopefully. But the cost of that was I have a lot more structured communication between different parts of the system, and that causes slowness, right? So there's another example, and there's a lot of these, right? And so most of the time, when we end up measuring things, what we care about is some important complicated combination of things that are good in and of themselves, right? I mean, a lot of times when you're talking about two different disk drive designs, you're not talking about which is better, right? That question has no meaning. What's important to think about is better for what, right? What are you doing with it, and based on what you're doing with it, how well we'll perform, right? All right, and this is, you know, this class, right? So when we start talking about benchmarks, what we talk about when we talk about benchmarks are pieces of code that are designed to isolate, potentially isolate, or essentially allow two different things to be compared against each other, right? So common benchmarking suites are released, they're licensed, you can buy copies, you can run them on your system, you can compare the results, right? And they're designed to try to give you a yardstick that you could use to compare different systems, right? We can break them down in a couple of ways, right? So, micro benchmarks typically try to isolate and focus zero in on one part of the system's performance, right? One specific thing that the system might do well or poorly, right? What would be the kind of thing that I might wanna try to isolate with a micro benchmark, Sarah? Like, what's one thing about a system that I might wanna test, like one very small component of performance I might care of? Yeah, okay, so that's an example, right? You're getting, but you can even get more micro than that, right? Like, what's one operation on your system that you might care about, maybe for like assignment three, something that you're working on that you might care about measuring the performance of? Jen? Yeah, so maybe swapping page to disk. What about choosing a page to swap, right? So how long does your page replacement algorithm choose? Take to choose a page. How long does the scheduler take to run? How long does a context switch take, right? For example, if you're doing IPC and a microkernel, you might care a lot about how long it takes to deliver a message from one process to another process. So these are kind of examples of micro benchmarks, right? We're trying to zero in on one specific piece of the system. Why would I do that? Like, why does that matter? Why not just, you know? I mean, when we start talking about Omdel's Law, we're gonna realize that these micro benchmarks can be quite misleading in certain cases. But why would I care? Like, why do I write micro benchmarks in the first place, probably? Yeah, so I might use a micro benchmark to try to locate the thing that is the slowest, right? So in general, micro benchmarks allow me to take the overall performance of the system and slice and dice it into other little pieces. Yeah, Jeremy? No, the answer was headed in a good direction. Yeah, it's what you have to do. Oh, okay, yeah. Okay, well, that's okay, you can just read the slide. Sometimes that's the answer to the question. Yeah, so, but if you're the, like, let's say you're the developer, right? Let's say you're writing IPC mechanisms, right? A lot of these other, a lot of the other types of benchmarks we're gonna talk about aren't going to express to you the impact of changes that you've made, right? You're now the developer of the Linux kernel subsystem. You care a lot about how long that scheduler takes to run, but if you just run these, you know, big system-wide benchmarks, all sorts of other people's contributions and changes are gonna start to muddle in there, right? So if you really care about one thing, and if that's your job, right? If that's the part of the system that you're responsible for, then a microbenchmark can be a good way to go, right? Cause you make a change, you wanna isolate the effect of your change, right? Macrobenchmarks are kind of the opposite, right?  So, you know, sometimes people call this sort of end-to-end performance, right?  And again, we start talking about Amdahl's Law. I mean, if there's 99 parts of your system that are really well-optimized and one part that isn't, but if that's the part that's getting run over and over again, then the system may be very, very slow, despite the fact that the microbenchmarks you run may show very good results, right? And then application benchmarks are usually geared more towards one application, right? So application benchmarks, you can almost think of as a more specific form of a macrobenchmark. They can sometimes be microbenchmarks too, if a particular application is incredibly, the performance of a particular application is incredibly dependent on one part of the operating system that might end up being a microbenchmark. But frequently, you know, an application benchmark might test a certain pattern of behavior associated with a particular application, right? So for example, database systems, you know, have these database-driven benchmarks that essentially test, you know, how good are you, Mr. Operating System, at doing what I want, right? Because databases have particular access patterns and particular sort of types of behavior that cause them to perform well or poorly on different operating systems, right? And actually, I mean, in the database community, there's been a lot of work on, you know, essentially like what to do about this meddlesome operating system, right? Like how do I get it out of the way as much as possible because there are cases in which it's, some things that the operating system is trying to do may directly interfere with database performance, right? All right, so, again, we went through some example of these, right? So, you know, handling a single page fault, maybe that's a little bit more macro, though, because maybe that starts to encompass a couple of different things, right? These are relative terms, right? You know, so macrobenchmarks, we might look at the page fault rate itself, right? Or the aggregate time to start handling a page fault once the system is under high load. And then, yeah, I mean, you can think of something like triple sort as an application benchmark, right? If you were writing an operating system that was designed to support sort for whatever reason, then you might care about being able to run lots of parallel sorts, right, on your system, right? You know, that might, you might care about, right? All right, so what are some of the weaknesses of some of the, I mean, we started to touch on them a little bit, right? But what's the problem, what's the problem with running, you know, let's say you were asked to do some performance analysis, what problem might you get into if you rely too heavily on microbenchmarks, Sam? Yeah, so if you miss, right, if you picked the wrong tree in the forest, right, then you don't necessarily get a sense for how well the system's going to work, right? So if I, yeah, if I end up running these micro, and this happens, right? So people start with assumptions. So if you do bad performance analysis, right, you frequently start with assumptions about what you think are wrong with the system, right? If you use those assumptions to choose microbenchmarks, then those microbenchmarks are not gonna help you determine what's actually wrong with the system because it turns out that there's this other thing, right, that's actually ruining performance, and it's kind of like you're totally ignoring it, right? Because you've already decided before you even ran any tests that that wasn't important because you didn't choose a microbenchmark that isolated that part, right? So to some degree, using microbenchmarks forces you to decide a little bit too soon potentially what's actually contributing to system performance, right? What about macrobenchmarks, right? So what's the danger of relying to heavily on a macrobenchmark? Yeah, not sure. Bethany, you wanna? Yeah, I mean, so this is kind of the opposite problem, right? So first of all, microbenchmarks end up merging lots and lots and lots of different parts of the system together, right? So the overall aggregate performance now starts to depend on lots of different pieces, right? And if you're trying to, if all you're trying to do is kind of figure out what's the fastest system, then you may not care about this so much. You may just wanna run some end benchmarks and you may say, well, for whatever reason, this machine is much faster than this other machine. I don't really care why, right? Maybe it just has a really, really good cash eviction algorithm, but I don't know and I don't care, right? And in certain cases, that's okay, right? But if you actually wanna do any more detailed analysis and or improve things, right? Then you start to care about what's the problem, right? Not just what relative performance is, but what is actually the problem, right? What about application benchmarks? Dan. Yeah, so I mean, there's this potential here. This isn't always a bad thing and we'll talk about this again on Friday when we talk about virtualization, but to some degree, some tuning that you can do for your system may improve behavior, may improve the performance for some applications while hurting the performance for other applications, right? And our application vendors that go so far is to say that we will only guarantee you a certain performance for this application if and only if it is the only thing running on your system, right? So you buy some sort of database server from, I don't know, some sort of database vendor and they're like, you bought this, you paid thousands of dollars for it, right? It's really specific, but if you run something, if you run your file server, if you run your web server on the same machine, who knows, like, sorry, we can't make any more commitments about performance at that point, right? And so you start to see a little bit about where hardware virtualization came from, right? And the type of the ways that people have used that to get around the problem, right? So Jeremy was hinting at this last time, right? The probably the biggest problem with any sort of performance analysis, right? And this is something that I think we're all subject to, right? It's just bias, right? So, you know, I was remembering, I mean, how many people, how many people remember the days of PowerPC Max? Do you guys ever own a PowerPC Max? Did anyone know what I'm talking about? Okay, good. So the back, you know, in the dawn of time, right? Max had this separate architecture that they used on their machines and they clung to this for a long period of time, right before they finally suddenly, inexplicably, gave it up and went to x86, which is fine. But there were always like these comparisons, you pull up, you know, the glossy computer magazines and oh, look, you know, here's, like you could be on one page and you could be looking at a graph of how, you know, Mac OS 9 on the MacBook Pro 2004 was just creaming, you know, creaming these Dell laptops at everything, right? And then you turn the page and it'd be like, Dell laptops are killing everybody else at everything, right? So it's like, you know, the benchmarks that you run, right, start to matter, right? And there's a lot of benchmarks out there and if what you care about is trying to make a claim about performance, and you know, I don't know, I don't wanna be too black helicopter here, right? But yeah, I mean, people, you know, let's put it simply, right? This is human nature and people have been known to choose benchmarks that make their system look good, right? And once you start doing that, it's very difficult to have a rational conversation with somebody because, you know, you and them are living in parallel universes, right? Like you're not, you're not, you're not talking about the same set of physical reality, right? It's like, oh, my system's faster, well, so is mine, right? So, you know, before you can actually start to have relative conversations about performance, you need to agree on benchmarks, right? You need to agree on how they run and what matters about them, right? And that's difficult to do. Yeah, and again, once you start, and then once you have communities that are choosing benchmarks, right? Then you do a lot of work to improve its performance and you're kind of like, you're falling more and more in love with that benchmark, right? You're more and more committed to that set of benchmarks, right? Because you're devoting time and energy to that relationship, like you want it to work, right? If you're trying to get it to, you're trying to improve it and over time that can be very difficult to say, well, you know, actually this benchmark suite isn't very good and I know that I've, you know, it's time to break up with it and go over here, right? And I have to do all this extra work, right? To get to know this new benchmark suite, right? All right. And the other thing that is also usually the case, right? Is that making, you can make any system faster for a particular application by simply making it less gentle, right? I mean, what you guys own and what we sell and what the computer industry supports, at least on consumer devices are these general purpose operating systems, right? That are really designed to be very flexible and run a large variety of applications, but making them faster it can be done if you're willing to sacrifice generality, right? And this already happens on the system you guys, the systems you guys are buying today, right? So what's one example, you know, can anyone give me an example of a case where we started to make a different trade off here, right? So a case where, you know, a system that's being optimized for something that in a less general way than we might be used to, yeah. Yeah, so various types of graphic optimizations, right? That start to force people to program in certain ways. Jeremy, what was? Yeah, okay, so server hardware, but even just like the general purpose hardware you guys are buying, right? What about Chrome OS? Uh-huh. Yeah, so okay, so maybe you might argue that that's just a reflection of like some change in the way that we're gonna design systems, right? Storage is dead, right? The cloud is the cloud is the future.  So, or decoding MP3s, right? I mean, you can write an MP3 decoder in software, right? But you can write a really, really much more efficient, much faster, much slower power one and just implement it out of a little hardware chip, right? You know, Wi-Fi chipsets, right, are an example of this. To some degree that can't necessarily be done in software, right? But that's why it's done, right? So there's always this trade off, right? The more general the system is in general, the slower it is, right? And this is not a perfect trade off, but you can certainly usually make things faster by customizing the hardware and making, you know, building more of a system around a single application, right? All right, so let's, we talked a lot about sort of what not to do, right? So let's start talking about some suggestions for good benchmarking and performance improvement, right? So the first thing is it's usually more, it's usually better to have a more specific goal than improving the performance of some piece of code, right? So why would it be, like, why a priori, right? Why before you've done any measurement or any analysis, why is it not potentially a good idea to start with this idea of trying to make a particular piece of code faster, right? What trouble would that get you into? Yeah, what's that? Yeah, I mean, so in general, how do you know that the code, the blob of code that you've decided to work on is the problem, right? You might think it's the problem, and this is the source of a lot of headaches for people, right, it's probably the biggest mistake people make when they're doing performance improvement is they start with this idea that this must be the problem, right? So why do people start with this idea? Why is this kind of a natural result of programming behavior? Josh, okay, so that's not a bad answer, right? I mean, how many people, if, you know, I asked you to improve the performance of part of your system of your OS 161 to this, and I'm trying to think of something specific, right? Like something in assignment two, maybe the, you know, how many people have I asked you to improve the performance of some of your system calls? How many people think they would know where to start? How many people think that there's this dodgy piece of code that they wrote that's sitting there in the tree that, you know, that it's not very efficient and it's kind of broken and, you know, it was done in some sort of dumb way, right? So usually when you start programming, you have these things in your code, right? Like that one part that you were kind of tired when you wrote it, and so you just did it in some sort of stupid, you know, really lazy, slow way, right?  It may or may not be the problem, right? So, yeah, so I mean, now Josh's answer is pretty good, right? So we have instincts about what's wrong with the system, right? Our instincts are rarely correct, right? Until you get good at this, right? Actually you've done this for years and years and years, I think you've done a lot of this. I'm guessing that trusting your instincts is not a great approach, right? So we talked a little bit about this, right? So when you start choosing models and simulators, validate them before you start changing things, right? So if you build a simulator, build a simulator and match it up with the behavior of your system before you start, right? If it doesn't match when you start, then you can't really make changes, right? You have to be able to understand the baseline performance before you do things and then use these tools appropriately, right? So use model and use simulation and run real experiments and this is something where, now I can tell you about it right here but this is something that you just get better at by doing, right? And I wish that we had a performance part of one of the assignments, but we don't. Maybe next year. All right. And then you can use these different stages, right? So typically modeling is a little bit easier and faster than building the simulator. Building the simulator, hopefully, is easier and faster than actually implementing it and pushing those changes out on a real product, right? So you can use this to kind of stage your ideas, right? If you can't convince yourself analytically that the idea works, don't bother with the simulator. If it doesn't work in the simulator, don't foist it on some poor customer, right? Or some poor person out there in the real world because it probably won't work in practice. All right, so, so far we talked about how to measure things, right? We've talked a little bit about benchmarks, what they are and different types of benchmarks that you might choose, right? So now, okay, so we've figured out how to do the measurement, right? We've decided what the system is going to do while we measure it. So now what? What's the next step here? Cal, Jen. Yeah, so now, like, potentially I might actually have some results to look at, right? So now I've collected some results and now this kind of gets a little bit more fun, right? Because now I have some data and now I can try to figure out what to do, right? So collect some data, try to use it to figure out what to improve, right? And then we go back to the top, right? Well, there was a beer drinking in here somewhere but in general, like this, and then we go back and, you know, you don't always have to choose new benchmarks every time, right, but this is kind of the loop that we try to get into, right? Okay, so this is just me, right? Maybe I have a tortured relationship with statistics. Maybe you don't. How many people feel good about their relationship with statistics? All right, okay, well, that's good. At least there's a few of you. So this, I was de, like, well, that's actually not true.  So that's, you know, that's how I made it here. But again, I mean, some people maybe just go straight, I could have gone straight from math and computer science. I probably would have been better, right? Just cut out the middleman. So, and, you know, again, this starts to, it starts to become socks, sort of embarrassing, right? Like, you know, so this is the, yeah, I'll run my experiment a few times and I'll collect some data and the variance will be huge, but I'll just make the variance go away. So I'll just compute the average and it'll be awesome, right? Because that's what averages are for, right? To get rid of variance, right? And yeah, maybe if the variance was small, right? Small enough to not be embarrassed by it, I'll put the airbars in my graph, right? If not, I'll just forget to put them on there, right? Because, again, that's what averages are for, right? Make variance go away. Yeah, so you guys should try to do a little bit better than this, right? And there's all these great tools out there now to help you with this, right? So you don't have to, you know, there's a lot of nice programs to help you with these types of things, right? So one of the things that I find helpful when you start doing data analysis is try to predict, try to use your intuition, and I know I just said not to, right? But you're not usually to make a decision, try to use your intuition to predict the results you're gonna get, right?  Say to yourself, what should this look like? What do I think it's going to look like? I know something about the system, you know, what would I expect it to look like, right? Then when you collect some results, you can decide, you know, you have some idea of do they match my intuition, right? So you're testing both your intuition and the real system. This is one of my favorite things, right? So, and again, people are fond of these summary statistics because the summary statistics are typically, and I shouldn't say typically, like summary statistics are designed to try to condense information about a system, right? So that you can talk about it in a slightly more rigorous way, but if they're very badly used, right? Then they can lead you in all sorts of wrong directions, right? So for example, here are two, so here is a set of, here's a variable that, imagine I collected some measurements of a variable, right? And this is what it looked like, right? This distribution has a particular median and a particular mean, okay? And maybe those are the results that you would report, you know, to your boss, right? Or the guy who's leading your product group, right? This distribution has the same median and the same mean as the first distribution, right? These distributions are very, very different, right? Yeah, and these systems are very, very different, right? So if you don't look at things like this, you're going to, so there's a story from a, you know, from a researcher I heard that there was very much about this kind of thing, right? They collected some data, right? They had aggregated it all together, you know, they were talking about it. I said, oh, it looks pretty good, but she asked her students, she said, well, why is the variant so high? What do you think he said? Anybody remember? What? Cash effects, right? Like, oh, that's cash effects, right? So she said, well, why don't you produce the histogram, right? So we can look at it together. And this is, well, this is what they found, right? The variance wasn't high because of cash effects, right? The variance was high because there were two different cases, right? There were two different things that were happening that were mixed together in the same data set, right? And as soon as they started looking at the raw data and they grafted appropriately, they started to understand this behavior, the system much better, right? This is a system where there's kind of one thing that's happening, right? And maybe there's some delay. So for example, this could be the average, well, it shouldn't be negative, right? But imagine this is positive. This could be the average time it takes your page replacement algorithm to run, right? And this indicates a certain thing, right? And it indicates that the running time is fairly predictable, right? This indicates something else. It might mean that the running time is pretty predictable, but there's two different cases here, right? Maybe, I don't know, maybe this is a case where maybe there's a bug in your out, right? This might be the consequence of that, right? And it's just a determined by, do you hit that bug or not, right? So this can be, these sorts of graphs can be really helpful to look at. So don't rush into this desire to compute these summary statistics, right? Look at raw data as much as possible, right? Okay. So outliers are, you know how outliers are our favorite thing to try to ignore, right? Because if we can throw out outliers from our data set, we can reduce variance, right? And then we will believe our summary statistics more and more. But outliers are, you know, outliers might, so outliers can indicate two things, right? In certain cases outliers are just some sort of problem with your measurement setup, right? Like, I don't know. I mean, there's all sorts of things that go wrong when you take measurements and if you see a measurement that's 10 times, let's say you're measuring a certain latency for a certain operation, you see one measurement out of your data set of 100 that's 10 times longer, right? You might say, well, you know, maybe I just messed something up, maybe. Now, if you can find some bugs in your measurement harness and I produce this, maybe you're okay. But the fact is that, you know, you have to respect all the data that you collected, right? So if you have that data point and that data point is really 10 times larger, then it's possible that that data point is real, right? It's possible that that really happened on a real system and that's something that you'll need to deal with. So there was some research that was done a few years ago on scaling commodity operating systems to large numbers of cores, right? So there's been an ongoing argument within the operating systems research community about whether traditional operating systems, sort of shared memory operating system designs scale to machines with like 48 cores, right? So can you take just sort of standard Linux and make it perform well on a machine with 48 cores, right? And what these researchers did is they took Linux and they started running on a machine with 48 cores and they found all of these performance problems and they just started fixing it, right? But a lot of them were these interesting cases where when you start adding cores, right? So if you have two cores, there are these certain very, very unlikely cases where these certain synchronization primitives could have very, very, very ugly behavior, right? That involves sort of coordination between cores. As you start adding cores to the system, those cases become more and more and more common, right? So what looks like noise in your measurement when you're on two cores, once you get to 48 cores starts to become the signal, right, that's all that happens, right? There's always some sort of collision between the two cores every time they try to access this data structure, right? So part of what they did is they just started running on a machine with a lot of cores, they started to see more of this and they started to fix those problems, right? But someone who was testing that system on a machine with only four cores would have been very tempted to just say, oh, that's probably just noise, right?  That must have just made some mistake, right? Well, it turned out, again, once you got to 48 cores, that started to happen a lot, right? And that was really, really affecting the behavior of the system, right? Okay, so let's finish with talking about Andal's law, right? So once I've done these measurements, you know, I've run into a mixture of different benchmarking approaches and if I'm lucky, right, I've identified the slowest part of my system. And now, clearly, the next thing to do is to improve that slowest part. Yeah, so this isn't that simple, right? So I just like this aside, right? So again, frequently, even if there was a slow part and even if it mattered, right? Like a lot of you guys would wanna work on that ugly part that you just feel embarrassed about, right? Like that part of the code is, oh, yeah, I don't want anyone to, I'm gonna go work on that. Your boss is like, no, I want you to work on that. I'm pretty sure that's not the problem, you know? We're in this other thing, right? But as nothing points out, right? Like without some relative understanding of performance and a profile of how the system runs, it's impossible to choose which one of these functions to improve, right? And there's a number of things that go on here. So it's not just how often things execute, right? So imagine, again, I have food that takes five minutes to execute, right? Some function food, I don't know what it does. I don't know why it takes five minutes, but that's how long it takes. And then I have bar, right? Bar takes five seconds, right? And so immediately I should get to work on improving food, right? But there's two things, actually. So Intel's law focuses mainly on significance, right? How often does food run, right? How much is food contributing to the overall performance of the system? But there's a second thing here too much I think is equally important to think about, right? Which is, can you improve food? You know, like, is there slack in food that you think that you can get rid of? Is food really lazily implemented, right? Is it using a lot of really simple and long-running algorithms that can be improved, right? So these are two things that you wanna start to allow to guide you when you start choosing, actually, what to work, right? So, but when you actually start, so the thing that we know about, right, after we've run these experiments is usually significance, right? How much is food contributing to the performance of the system, right? So Amdahl's law has a mathematical statement, right? But what I like is the more colloquial formulation, right? Which is that the impact of any effort to improve system performance is constrained about the performance of the part of the system not targeted by the improvement, right? So essentially, if I pick a piece of the system to work on, even if I make its runtime vanish, the system will still take some time to run and the time it takes to run is now constrained by everything else, right?  Who can give me, who can come up with a colloquial way to apply this that doesn't have anything to do with computers? Well, what's an example of an application of this to our modern life? Sean, okay, yeah, no, that's interesting, right? So the effort to optimize your drive time to school by speeding, I'm sure nobody here does because it's against the law, right? That is limited by the time you spend, spend a stoplight. That's a good one.  Hybrid cars? So, yeah, okay, so how you, right, so how you operate things matters, right? If I'm flooring my hybrid Prius out of the lights, probably not gonna help. You know, I don't know, maybe it's just my political tendencies, but you know, the effort to reduce the United States budget is constrained by the fact that like 90% of it, or 95, something like 90% of it is stuff that you can't actually get rid of, right? So you can have arguments about, you know, reducing spending, but they're, you know, unless you're really gonna carve into things that people don't like to give up, you're not really gonna get it, right? You can reduce discretionary spending by 50%, right? And you've reduced the federal budget by 5%, right? So anyway, so let's go back to computer science, right? So imagine that, you know, I have, now imagine that I've done, you know, somehow I knew, somehow I knew that I could do this, right? So I have the option of reducing the execution time of foo by 80%, right, from five minutes to one minute, and reducing the execution of bar from five seconds to four seconds, right? This is a 80% improvement, this is a 20% improvement, does anyone, can anyone predict the speed up that this will have on the overall system? Anybody? No, nobody can, right? And, you know, well, okay, no, I can, right? I'm gonna say foo is better, right?   Well-educated people, right? With degrees from like prestigious institutions, many of them will be degrees in business administration, unfortunately, right? Sorry, that was a low blow, right? But yeah, your boss is gonna be like, come on, man, like, just come on, just go work on foo, you know? 80%, you know, like that's something I can make a PowerPoint slide out of that number, right? You give me a 20% improvement, I don't know, you know, I might need some fancy animations to sell that. But yeah, look, like, this is gonna be in the glossy magazines, right? Like your bar just went like, wow, cool. Unless the program spends over 95% of its time running bar, right? And only 0.1% of its time running foo, right? So you can do this math if you want to, we don't have to go through into detail, but, you know, the speed up that you achieve by optimizing bar turns out at that point to actually be better, right? And these are pretty huge differences, right? Like this is a function that's taking, you know, 60 times longer to run, right? And the improvement is four times larger, right? But still, if bar is my hot path, right? If bar is the thing that the system spends all of its time doing, then bar is what I work on, right? So if you go, you know, do server, I think I mentioned this before, right? If you go do server performance optimization, right? They actually spend time, you know, looking at assembly code that's run by the system frequently. And if they can find like one place where they can like reverse a few instructions, you know, maybe I get something into a delay slot and it's like sweet, you know? I just sped up windows by like 1%, right? With a single instruction, that's an exaggeration problem. But, yeah, so you start to look at things that, yeah, yeah, look at this, who wrote these slides? So, yeah, so, and this is another sort of, you know, colloquial, even more colloquial way, maybe this is a way that you can use to talk to your future bosses about Amdell's Law, right? It's like, look, this thing's hurting us, right? Like this little piece of code, I know it doesn't look significant. I know, you know, you don't think it's that important. I know the improvement that I can offer is maybe now this big, but it's killing us, right? That's the thing that's actually hurting us. And then here's the other, here's I think the other sort of, I don't know if it's unfortunate, but it's kind of an interesting corollary to Amdell's Law, a result of Amdell's Law, right? So, okay, let's say you're good, you run your benchmarks, you've done your statistics, you've found the right part of the system, optimize, you start working on it. As you improve that part of the system, what happens to the overall system performance? How do I have to reapply Amdell's Law? What's sort of the continuous version of Amdell's Law? Nothing. And so what's, yeah, so essentially, the more, you know, what Amdell's Law will say is that the more you improve one part of the system, the less likely it is that you're still working on the right part of the system, right? And of course, this is frustrating for people, right? Because they spend a lot of time working on this, they think, oh, I can get 10% more if you just give me another week or two weeks or a month or a year. But the problem is that they're not working on the bottleneck anymore. You know, this is the result of success, right? Like you've done your job, like that part of the system has now, and it's kind of like whack a mole, right? Like you whack that mole, right? Like it's down, that there's other moles popping up all over the place, right? So you've got to go after those guys. So yeah, so I think this is the other thing to keep in mind, and it just means that, you know, you have to stay agile, right? So as you're working on systems, as you're optimizing performance, you have to keep in mind that you have to repeat, right? So you have to continuously go back to the top of your loop, right? You've done some work, you've optimized a certain part of the system, you've replaced some sort of, you know, inefficient algorithm with a more sophisticated one. Now you have to reassess, right? Because now it's going to turn out that some other part of the system is actually needs your attention, right? All right, so on Friday we will talk about, we will do a lightning tour of virtualization for fun, because virtualization is cool, and I will see you on Friday.


This is going to be a demonstration of the small intestine, in front of us we can see this is the aorta and this is the supramacentric artery and we can see the branches of the supramacentric artery. Just to bring up to speed, this is an aberrant artery which is going to the right lobe of the liver, this is the first branch, this is the inferior pancreatic urinal. Thereafter we can see these multiple branches. These are all the colic and the gingeral and the ilial branches. So the supramacentric artery is the artery of the mid-cut. The next artery I would like to draw your attention to is this one here. This is the inferior miscentric artery, this is the artery of the hind-cut. This supplies branches to the descending colon and after that it continues into the pelvis as the superior rectal artery which we can see here and supplies the rectum. Having mentioned these arteries, now let's demonstrate the small intestine.  We have completely disemboweled it from its attachments. Right away we can see the small intestine is highly coiled and it is incorporated within the abdomen. It is approximately 6 to 7 meters long. The proximal two-fifths is the ginginum and the distal three-fifths is the ilium. Let's take a look at this fatty structure here. This is the miscentry of the intestine and within the layers of the miscentry are ramifying the blood vessels and that is how the blood vessels reach the small intestine. This small intestine is derived from the mid-cut, so therefore all the vascular supply is from the branches of the superior miscentric artery. The surface which is attached to the miscentry is referred to as the miscentric border and the opposite side is referred to as the anti-miscentric border. So the blood vessels enter through the miscentric border and then they ramify and go to the anti-miscentric border. Now let's take a look at some basic differences between the ginginum and the ilium. So we are holding up the ginginum which is very close to the due to the ginginum flexure. We notice that the ginginum is thick, fleshy and more vascular and in life this will be more pink in color. The next thing we notice is the miscentry. The miscentry is laden with fat but it is much less compared to the ilium. We have cut open a section of the ginginum to show the mucosal pattern. We can see that the mucosal folds are transverse and they are very dense and they are very big and this is referred to as pli-case circularus or belbule conventis and this is what gives a feathery appearance when we do a perium male follow-through. This is a perium male follow-through to show the feathery appearance of the mucosal pattern of the ginginum. In this section of the miscentry we have removed the layers of the miscentry to show the blood vessels. To demonstrate the blood vessels I am going to hold it up against the light. We notice that the blood supply follows a particular pattern. We can see this curved vessel here. This is referred to as the vascular arcade. Emerging from the vascular arcade we can see straight vessels going to the intestine itself. These are referred to as the vasarecta. So in the case of ginginum there will be very few vascular arcades mostly only one. Therefore the vasarecta are long. Now let's take a look at the ilium and see how it compares with the ginginum. Now I am holding up a section of the ilium which is very close to the iliocecal junction. Again let's take a look at the intestine itself. We can see that the intestine is much thinner. It is pale. It is less vascular. Now let's take a look at the fat in the miscentry. We can see that the fat in the miscentry is much more dense and not only that it is encroaching on to the intestinal wall itself. Now let's take a look at the interior. We have cut open a section. We notice that the mucosal folds are not as prominent. They are fewer in number and as we go further distally they will even be absent. This is what is referred to as the structuralist appearance as described by Wangenstein in a bearing lead follow-through. In one section of the miscentry we have removed the layers of the miscellaneous baritonium to show the vascular pattern. And again I am going to hold it up to the light and we can see that the vascular pattern is somewhat different from that of the ginginum. We notice that the vascular arcades are severed. We can see one main arcade here and we can see further subarcades more distally. And then extending from the apex of the arcades we can see that the vascular arcades are smaller because the vascular arcades are extending more distally. So therefore vascular arcades are more, vascular arcades are smaller in the area. Not visible in this section but if we want to take a microscopic view of the submucosa we will see erections of lipfoid follicle in the submucosa which are referred to as pairs patches which are more numerous in the area. So these are some basic gingino ideal differences. Finally just for the sake of comparison I am going to hold the two sections close to each other so that we can see them and have a comparative view. This is the ginginum, this is the alium.  Single vascular arcade, multiple vascular arcades. Long vassarector, short vassarector. Ginginum is thick, fleshy, alium is thin. More vascular, less vascular. So therefore to summarize, alium is thin, thin with fat, vascular, mis-entry. One or two words of clinical correlation. Interstitial resection and astromosis is a very commonly performed surgery. When we have to resect a particular section of the intestine, small intestine for any reason whether it is gangrene or whatever we first ligate all these blood vessels right from here till here and then we ligate them from here to here and after we have done that we clamp the segment of the small intestine and we remove it. Thereafter we anastomose the two ends together and so this is the basic principle of doing a resection and astromosis of the small intestine. Point to be remembered is because the alium is less vascular we have to make sure that we do not jeopardize the blood supply when we are doing anastomosis because alial jeopardization of the blood supply is more common than that of the ginginum. These are some of the points which I want to mention about the small intestine. Thank you very much for watching Dr. Sanjay Sanyal signing out. Dr. Govthi Chunilal is a camera person. If you have any questions or comments please put them in the comment section below. Have a nice day.


Thank you very much indeed, nice to see you all here. What I'm going to be doing this afternoon is to look at the way that maritime archaeology was created by the fallout from the end of the First World War and the interesting route by which items went from piles of metal, a bit only for scrap, ases just within the century which separates the armistice in 1918 from today. Now the armistice of Korpion as it was called on the 11th of November 1918, 11th hour of the 11th day of the 11th month. Part of that was the dealing with the German navy, in particular its submarine. The German submarine force Church had come closer than any other part of the German armed forces to forcing the UK's defeat during the war. it was a very, very close run thing with the destruction of Merchantment in the Atlantic and as a result, the submarine, the German submarine was held up as a particularly eviled element and this is brought out by the Armistice, because very well then Armistice it is simply an agreement stop fighting for a bit it has an expiry date and actually provided a pose however the armistice with Germans included item 22 which actually included the surrender of their submarines not just simply put them into some kind of status until until peace treating but actually ac yn eich amlwg o'r amysgwyr. A oherwydd, y 23, o'r wybodaeth cyntaf, yma yw'r cyntaf gofyn sy'n ei bod yn ei wneud ar gyfer, i'w bwysig ar gyfer animaeth, fel y pysgwyr wedi ei wneud.  Rydych chi'n dweud i'r rhaen i'r rhaen i newid i'r ei ddarladau oes dyma. ac ydyddwch yn ystod o myfyrwch i'r pernod iawn mewn i'r llyfr hwnnw ac yn yw'r rhan o'r parwyr a'r ysgrifennu. Felly ydych chi'n ei fod yn ystod yn ymweld i'r opaiddio ac yn ymweld i'r parwyr yw'r tro i fynd i'r own fawr. Ond y gweithio, o'r dygatant, i'r armysg ac yn gweithio sy'n credu fyddio'r parwyr sy'n credu'r llyfr hwnnw mwy o'r llyfr hwnnw, ac yn yr ystod, mae'r gwybod fel y bwysig yn cyfwyr hwnnw, mae'r gwybod yn ymddangos i'r trofyn, mae'n gyda'n gwneud yn ymddangos, ac maen nhw'n gwneud yn ymddangos i fi wneud yn gywir i'r gweithio'r ffordd. Felly mae'n gweithio'r eistedd o'r cyfrnod, creu y peth yma i'r sgwrdd yma, oherwydd yma i'r argymryd yma argymryd. A gyddi'r pethau ar gyfer yma ar gyfer y suwr yn ymddangos, A rydych chi'n gyd wrth yr ddweud mae'r rhaglaethau llwyddon yn ddau, ond a gweithio'r cyfrifio o'r llwysbeth eich ddau. Yr eich i oeddaeth fydd.  Llaer-Flw wedi bod i'r pas o'r Ffordd y Prify LO ond yn dweud i'r Fflerd Rhe fruits ac mae'r bwysig iechydol yn y bwysig o'r cyfle a'r dynnu bod yn gwybod i'r twro'r troi. ac here between November 1918 and June 1919 the pride of the German Navy was left to a righted anchor. Gradually the crews were taken off and so by the time you get the summer of 1919 only a skeleton crew are aboard these things just enough to keep things ticking over um in some cases with some of the smaller ships you had a few people who were dealing with more than one ship at a time they were affecting his caretakers. Of the surrendered German submarines although actually who was going to get what was a matter for interaeride agreement quite a few were used for propaganda purposes they went on tours around the ports both of the UK and also of North America to show off the spoils of war effectively and the just a couple of shots of some of the visits. There were a number of separate tours going on by a number of different boats and one in Bristol there nowadays that's actually a traffic island where those where those submarines are it's always interesting looking back at these old photographs where you have to please you know well to realise how much things have changed over the years. In addition boats which were not even fit to be towed across the North Sea were broken up and here we've got a few of the German submarines half finished now being dismantled in Germany. The rather odd appearance of these is what you've got loads of mine tubes these are mine layers so each of those uh those what was looked like the funnel sticking up had a whole load of mines in them which would drop out in the bottom of the submarine and um to form a mine field. In addition to the submarines themselves also anything which would support a submarine was also um to be surrendered and this was a rather interesting ship was designed to actually salvage sunken submarines. It's a catamaran and if a submarine has sunk it will lure itself over that submarine put cables down and lift the thing off the bottom of the sea. This one however they're not redesigned for sea passage. Most of these things are designed for salvaged each of sunken harbour and in what happened in this particular case was it's been towed across there was a storm and she went down in that storm. It wasn't just things like the like Vulcan which ended up not quite where they were supposed to. Harwich was getting remarkably full if you think of an entire submarine fleet being put into a single harbour um it was running out of space so therefore in the beginning of 1919 it would decide to start to divvy up some of the boats not necessarily definitively yet but just to make room so therefore the French agreed to take a whole bunch of them and therefore a series of boats started being towed from Harwich through the English Channel down to Cherbourg to be um to be looked after there. By this time however they've had a few weeks and not really been looked after properly um with the crews had gone back to Germany and submarines require constant attention so therefore they were having to be towed and also um as they were going through the English Channel a number of them got caught in storms and rather most spectacularly the U118 ended up on Hastings beach here. It was quite a major tourist attraction um until um there was a rather nasty act that somebody fell off it um at which point um the police were trying to keep people well away well away from it. There was no way you could get the boat off the off the beach and therefore um she remained there um until broken up and she was one of a number of different boats this actually happened to. Um there's another one here the UB 121 um that the the the wreck this is this is in Berlin Gap down on the south coast and the ship on the right there um is a merchant one which had run aground during the first world war and showing how the tides almost inevitably leads the same sort of spot UB 121 came off the um off off the tow rope and ended up on the beach alongside here and remains of UB 121 still there. The identity of some of these boats and some of these other wrecks has been something of a mystery or at least a sort of local legend because in this there are various standard works have been published on German submarines of the first world war and so as with so often when something's in print people tend to believe it and fortune's quite clear that some of the the the fates were somewhat guesswork and a lot of and first for some time this boat was misidentified as UB 21 or even U21. The trouble is also local that the newspapers at the time didn't know that for a U boat a UB boat and a UC boat they are different things. A U boat is a big one a UB boat is a little one and a UC boat is one which carries mines but people would see UB as a sort of a U boat. So there's a very interesting the research which lies behind this talk and the book which they is currently impressed involved a lot of work in the archives just trying to unpick some of this stuff and another nice case study from that I'll be talking about in a moment but these say all of these these these losses in tow produced a number quite interesting wrecks some of which are still accessible to divers today and a colleague at Bournemouth University has basically dived every single one of the wrecks in the English Channel and identified most of what most of these these these boats again some of them aren't actually where those reference books say they are so there's a whole the trouble is what I think in a reference book it seems to stay there what we hope this project will will do is actually get some of those things revived but those are all quite small and compact wrecks on the 21st of June however some rather bigger archaeology began to be created because during the summer early summer negotiations had been going on at in Paris towards the German peace treaty but I say negotiations negotiations were between the allied countries about what the Germans were going to be told to do there was no possibility there was no part of negotiation by the Germans in this effectively they were called in and told this is the treaty sign it anyway and under that treaty the Germans were going to lose pretty well their whole navy to the to the allies including the vessels which were interned in scaper flow and as a result just before that the treaty was signed in fact the 21st of June was supposed to be the treaty signing date but the Admiral commanding the German ships and scaper flow hadn't been told it had been postponed for the 23rd the signing so on the 21st which restored me in the third day they basically pulled the plugs out of all of the ship it looked a bit more complicated than to be putting a plug out but basically opening every kind of valve which lets water into the hull and therefore the half of the German navy slowly sank to the bottom of the scaper flow it has been said that there are suspicions that the british were sort of aware of this and let it happen because on the day in question the british fleet had been guarding them for months on end went out for target practice so actually when the when the valves were open there was only a couple of British destroyers left in scaper flow which made an attempt of towing some of these things but a destroyer and a battleship which is full of water is very in particular efficient had the full fleet been in you could have used battleships to tow battleships and get them to the shore the thing was that alongside deciding what to do to the German armed forces there was a big debate among the allies about what they should do with the stuff once they've got it the british and the americans were of a view sink or scrap the lot however the french and italians wanted some the japanese mission was if the french and italians got some they wanted some so and there was a likelihood of a particularly major row over who've got what and whether they can actually keep it or scrap it or not had the full fleet been been available particularly the most modern ships run which were the ones in scaper flow so there's a suspicion that the british may have been sort of aware of all of this and let it happen on the grounds that if they're all in the bottom of the sea the row has become rather less problematic there's i've been through all of all the old files for this there is no trace that anybody was sort of typically was sort of had this in mind but one had a very rather strong suspicion why would you know give me around a couple of days from the treaty signing date which is probably the high point of any dangerous scuttling do you take your whole fleet to see for target practice can't you wait two days there's all the plans for that for storming these vessels the moment the treaty was signed so there's a strong suspicion that the uh there's a bit of a the British were British weren't too disappointed by it a couple of ships were actually kept float or bait or beach there's a couple of them there the only battleship the biggest the biggest one the barb and is there being beached and the one the Frickruder's Frankfurt but the vast majority of the fleet was ended up on the bottom and so there's a little map of all this of the Orkney islands showing Skapper flow and there you can see where all these various ships end up sinking in addition to these ships which which ended up as wrecks through the scuttling there was one German destroyer which had been shuffling backwards and forward between Germany and Skapper with the mail and she arrived just a few shortly after the last of the ships had sunk so she was then pounced on by the British which then again sort of decided to her off to Rossife the nearest main but the naval base unfortunately she got caught in a storm and ended up on the beach there she basically remains there today not quite looking like that but she's still there these are recognisable remains and then she becomes another part of the archaeology of the armistice and a gun from her was salvaged and is normally on display up a Skapper flow but was taken down to Portsmouth last year for an exhibition for the centenary of the armistice so that's by the main gun to the B98 of the ships that were hadn't hadn't had been beached they were all fairly rapidly refloated by the Royal Navy and most of them were then divided up amongst the various allies but with the proviso that they had to be sunk they couldn't be put into service in fact because most of them have been filled with waters of some greater or lesser degree the engines were fairly well ruined also some of the submarines by now were being formally divided up between the various allies only the French were actually allowed to put any of them into service basically because they not had a chance to build submarines during this first world war because their main shipyards had been in the German occupation or the works had been diverted to the western front so the French ultimately were allowed to keep a few ships um including the only one everyone's allowed to keep submarines the rest were then destroyed as targets and here we've just got to the target practice all these target trials carried in carried out during the autumn of 1920 when the German battleship Baden is um is fired on in the English Channel and as are a couple of destroyers and also a submarine or the which can be seen there Baden ended up on the bottom of the channel but the destroyers although quite badly battered were towed back into Portsmouth and here's rather splendid um painting in the National Maritime Museum which shows one of them at run aground in Portsmouth Harbour and she's still there adding to the archaeology of the of the armistice although she doesn't look like this anymore this is basically what she looks like today along with another boat which was also fired on in the same trials the the 44 the the fact now that these are now regarded as important historic monuments but that of course wasn't always the case which is by the reasons why they're in the state the art at the moment the wrecks were sold for scrap then bits were taken off them resold once again then one of the wrecks was cut in half when they were dredging for the ferry terminal which is um at Portsmouth here and then almost forgotten about until the run up to the first world war centenary when suddenly people start taking interest in these things again and they actually were made headline news and newspapers when they were done every new they existed if you were in the in the know but the the very existence of these things had been completely forgotten about in the popular imagination so therefore we have these um we're now we're once of undeserved trifles and now we're regarded as key pieces of the history of the first world war other vessels were also used in these trials this is the painting of the June Trudeau Nuremberg which is also now at the bottom of the channel as a result of the of these firing trials which took place in 1921 so this is really showing what is thought about these these leftovers from the first world war they are simply sort of scrap metal or quite a nice thing to use for target practice there we have Nuremberg in the middle of the channel with also barden shell but also what we can see there is the number of german submarines which are dotted around the channel and these and say these are not this is this is nothing to do with the sinkings during the first world war all of these are simply the flotsam and jetsam of the armistice some of them were as we talked about earlier on um results of um results of shipwreck while being towed to breakers um for example here's going to see you 118 um off but that's um hastings there uh the ub 121 and a little bit in the east born at berlin gap and most of these ones are on the coast there are the results of that the exception to this accidental loss of the ones in the channel here anyway is the block of them directly south of the isle of white because although the French have been allowed to keep some submarines the the whole horror which i mentioned right at the beginning of this lecture about what submarines could do meant that the internet inter allied agreed that everything else had to be destroyed by the middle of 1921 whether it by scrap um sinking as targets or simply scattered things the ideal could be to scrap these things as part of the um recovery after the first world war there was a greatly scrap metal and therefore trying to funnel these things through the scrap yards was the idea the trouble is also the british navy was demobilising in this period and a lot of the british navy was being scrapped as well so the problem was that the scrap yards were simply filled to bursting and we and it got to a point in early 1921 when the inter allied commission which oversaw all this issued a list of things which should be destroyed within the next few weeks or else kind of way and as a result there were a number of submarines bobbing around in harbours there was no way of selling them for scrap or at least there was no scrap merchant who was prepared to actually break them up sufficiently to qualify for the rules um there had to there was a point where they had to be such incapable of further service which was further properly defined in internet inter allied agreements so therefore it got to a certain point where even if they could be sold they weren't big it couldn't be done under that basis so therefore in the summer of 1921 a whole bunch of new votes were towed out into the channel and simply sunk because there was nothing else you could do with them to stay on the right side of the inter allied agreement so a lot of those were just south of the um either white are um are those then exception to that i think is the you is the U 90 which um sank accidentally well being towed to be linked to the Belgians um it was it was for a short while the only submarine the belgian navy ever possessed unfortunately they actually made it to um made it to belgian it managed to spring a leak halfway across and is now at the bottom of the channel along with so many others other apart from submarines there are a fusion of other surface vessel wrecks for example here off um torbay that kind of that area in there we have the t189 which was being towed off the scrapyard unfortunately got caught in a storm is it remind when actually that even this channel is not a particularly peaceful place uh got caught in a storm ended up on the rocks and the remains are still there just off round them head off painting and haste things also seem to be quite a good place or bad place to try and tow something by is another of these submarines which was trying which was on route to to france and never quite made it now what probably the largest concentration of wrecked german submarines is actually a phalmer and in most of the local history books and so on it's recorded these bluer shore in a storm in 1921 which didn't actually happen at all another of these little factoids which this research has been so that has been digging out actually what happened was a whole bunch of german submarines would get used for explosives trials and the way this was done was to make sure you could control how deep they were when they were being blown up and also you didn't have to have people on board them which might be a bit dangerous if you're using explosive charges remember the vulcan the salvage ship which i showed earlier on well her sister ship didn't sink on the way across and they decided to use it almost in reverse so rather than pulling submarines up to lower submarines down to a depth and then let off charges around them and then you could then winch them back up again even if you have blown holes in them just think like that and this is the ub 112 in exactly that position about to be lowered down to be then be blown up and when they finished with blowing them up they weren't in particularly good state so they are all then just dumped on the shoreline um they want the 112 again after she has suffered she's been used for trials and so therefore you have this that there's a whole bunch of submarines during 1920 when littered along the foreshore at Falmouth you can probably see why the idea these might be blown ashore in a storm it looks like the result of the storm doesn't it and people just put one or two and two together and made 97 and a half in this particular case whereas when you actually go into the records it's quite clear that these have actually been purposely dumped here to keep them above water they were then sold for scrap but they were quite difficult to work on and there's still quite a bit of them still there so in um on the on the waterfront of Falmouth they are low tide there's lots of bits of twisted metal visible and that's that's them so that's the largest concentration of sort of archaeological German submarines anywhere in British waters another sort of bit of myth is in the medway now where i've got marked on the map here are three German submarines one of them up in these two creek and two of them in Sleid Creek these again were so have been forgotten about until the run-up to the centenary of the great war when particularly the one at East Hoot Creek the best preserved of them was rediscovered quote unquote there she is amongst mud flats of the medway at relatively low tide and a closer view with a little bit more water but an awful lot of mud now her identity has been a matter of local it's always that was a study of folklore actually when you're looking at the identity of this because she has been given all kinds of identities over the years when she's been at least the time when she's been sort of visible to people um and actually on google earth she is down at the ub 122 unfortunately the ub 122 was some was scuttled in the um English Channel of the Island white in 1921 as part of that dumping program i mentioned earlier on i've just actually put a correction into google earth whether or not they will accept not as an interesting interesting thing whether they accept that or not but in fact when you look at it all the way when you sort of look back at various local newspapers internet postings all of them are are effectively guesses based on why the standard work are these standard works which has a whole bunch of boats listed as lostings hose the breakers of the east coast of the uk not a single one actually was and but but this but when they were trying to work out which what this boat was though that was for the basis happiness and and the result came when a colleague up at Newcastle University unearthed in the Royal Naval Archives at Portsmouth the the navy's scrap register for the pier from 1919 to 1929 because as the british were responsible for all of these things which have been these boats everything went through the admiralty records and i spent a long time trolling through all of the list of all these submarines coming to british hands in 1918 1990 and finally i don't know but there are three submarines in the medway i found three boats sold to a company in the medway and noticed dumped 1922 so therefore these there are three which one is which i don't will ever know particularly because all of these particular boats whether it were the incomplete ones being towed across without engines and so on so the the hope of having makers players or a stamped propeller or something like that is normal way of trying to identify these things but i think we can certainly say that she is one of these three and also another issue has been some of these ships she's been identified with don't actually look like this at all when you look at the plans it's quite clear they're not she's not one of those anyway she's got me one of those and then the rather more broken down ones a bit further up the medway also have to be the other two of these submarines but the whole exercise but when they've had these have never been previously posited as potential candidates it was only when one of those went back went back to the archives and found this hitherto unused source that we were able to work out what the candidates for these things are i think the whole project very much has brought home something i was always aware of but you have to be amazingly careful with what you read and what the and question what the sources are in my wearing my other ecological hat as history changes almost a weekly basis as new as new data comes about but it's also true even with recent stuff where you have this vague assumption that we know it because it's over a hundred years old clear the records must be accurate therefore the books must be accurate mustn't they it is a real good example of where they're not now let's go back to scaper flow originally the thought was to leave these ships to moulder on the bottom of the flow until fishing boats started running aground on the bottoms of battle cruisers at low tide at which point it was decided to sell them for salvage and scraps so most of the destroyers those little ones at the bottom had actually been run ashore and were already being either sunk as targets or or broken up but the big big boys and girls the ones up at the top there which are the cruisers battle cruisers and battleships were still under water and it was these so there's there's the destroyers they were easy enough to get up run more difficult is when something is still is well and true you know is is tens of meters underwater and much much bigger than that so so the destroyers easily enough got up and here's just one of them being strapped but what about the bigger ships these much more impressive ones well a couple of them still had bits of them above water and therefore in 1926 they tried to salvage sidelets here nobody's actually trying to salvage ships like this before it was all bit trial and error and it was a bit of a comedy of errors given the side it was eventually salvaged towed down to the side and scrapped but it didn't go quite as they hoped it would but they gradually got the system part of it was that the ships were actually floated floated upside down at which point all the turrets fell out of them which then had to be salvaged separately because all these ships had capsized when they were some when they when they when they were scuffled and in fact it's easier to to reflow the ship upside down than the right way up you don't have to do is seal the holes if it's the other way up you've got all sorts of problems about where to stop the water coming back in again so that is the picture of a whole whole procession of german battleships and cruisers which left the left scap of flow to be towed down to um or side to broken up and dried off and gradually between the mid 1920s and 1939 a series of the ships were salvaged at least a ship a year was being brought up it was almost an industrial scale kind of process the last of the ships to be salvaged has been salvaged just before beginning of the second world war it was the battle to the deathlinger and she actually ended up just floating upside down in scap of flow for the whole second world war in fact she spent longer floating upside down she's actually spent up the right way in service during the first world war and fine and it was until 1946 that it was possible to dock her and to demolish the remains and there's the what an upside down when you break something upside down the last thing you break up is the deck which is quite an interesting way of looking at at these things but there were still some ships left on the bottom and after the first second world war there were these all still left on the bottom there wasn't really too much appetite for getting them up because all the equipment and expertise being built up to salvage all these other ones off to the off the left there had effectively gone during the first or second world war but there was an attraction of these so i'm still nothing to do with the fact that these are at the last remains of the german high seas fleet or any idea that these are historic wrecks it's because they were all built before something happened in august 1945 the atomic bomb what happened when when the when the bombers were dropped on Hiroshima and Nagasaki radioactive radioactivity in the atmosphere was massively increased and therefore it meant that any steel snelted from scratch after that point has a level of radioactivity which which steel earlier than that doesn't which is normally not really an issue however if you're doing things like rooms for treating of cancer patients where you need to have shielding and various other very very very precise scientific equipment and those kinds of things you don't want there to be any trace of radioactivity in the steel so suddenly in the 1950s when this became apparent there suddenly became a market for old steel ideally armor plate which is the highest quality possible and so suddenly during the 1950s the market for old warships particularly very old warships became and the scrap world became pretty good and of course these are very very definitely free atom bomb and therefore during the 1950s they began to resume salvage but nobody was going to actually bring these things up anymore the key thing was to get the valuable stuff out of them so therefore divers would simply go down blow open the bottoms and use grapples to get the interesting stuff up and that continued on through into the 1970s when when gradually a realization of these things actually are historically significant comes about it's amazing actually it's not until until probably the 1970s that sort of old mechanical stuff really becomes something people care about the number of historic ships of other things which were broken up you know in the 1960s now after the you know the beach the beaching acts most uh steam steam locomotors just went went to the went to the uh the breakers and the same on the maritime front for example the you know the the fact that they just met warrior and the ss great britain survived different people were accidents they just happened to be still intact when we get into the 70s and people were starting to be interested in this kind of stuff and that starts to happen with these it's a recognition that these are the last remains of the german high seas fleet the last floating bit of it have been broken up in turkey in the early 70s the turks had acquired a joint battle cruiser during the first world war and it remained part of their fleet until the 1970s but then with her gone this was really all there was and therefore no more salvage was allowed on these things although a number of them had actually been sold off were actually no longer been sold off and were not actually owned by the admiralty anymore but there were still salvage rights and so on there was some regulation which could be done on them and so therefore we've got on the bottom of scap of flow and since 2001 have actually been protected monuments we've got curnic as you can see she's about ship shape you can see that she's been she's been knocked around a little bit by the salvagers the same goes for the cruiser brawler part of this is a bit that bits have been blown over for example you could be around here is the engine room which has been blown over because that's where you find interesting metals not just simply pre-atom bomb steel but you also find brass and all those things which are worth a lot of money but also time is also attacking these things it's fairly it's fairly thin steel and you're getting to a point where some of these these wrecks can't be supporting each other support themselves anymore another one curn again engine rooms been blown open rest of it just gradually starting to to fall further into decay another one Dresden still down there again note engine room been blown open the poor Carl's row is probably the least salubrious looking one now she's she's well on her way to decay but at least that's only nature which is now working on her rather than the explosives of the salvage men you see all of these ended up these what the big ones ended up upside down on the bottom hence for other reasons why they were salvaged away and there you've got her mass broke off as she rolled over from Prince Wilhead and probably best preserved of them is the map graph the well the last one to actually sink in 1990 and again you can see the pattern with the engine room broke blown open also she's had it blown open here as well is where her torpedo tubes were even battleships during the first warhead torpedo tubes on the front and they are also off brass and other interesting metals so these are probably the best example of the way that this heritage of the underwater heritage from the fallout from the armistice has gone from so sorts of just simply something dumped something to provide just to get scrap metal and now these are part of the tourist industry of Sapa Scapa Flow it's one of the great dive targets in the world where else can you swim around the battleship in only 100 feet of water or so so these have really now become part of that there was an interesting little sort of twiddly bit recently almost a mark as I said some of them had been sold off in the 1950s and have then been sold onwards there was actually an eBay auction of the three battleships and one of the cruisers because the guy who actually had still owned the legal the legal rights and they were indeed sold I think I think a battleship of 25 000 pound or something like that the owner I think I don't think they've been made public can't do anything with them they can't because they're now registered as monuments salvage rights you know are no longer in existence but you know you can still own a second a first world war german battleship if you like now the german high seas fleet is of course there you know this is this is what you've got left for the directly but there's also a few things above water for those interested in the maritime heritage of the first world war so the german fleet a few bits of it still are on the bottom of Skapper but down at Portsmouth you've got HMS M33 a coastal bombardment ship from 1915 which you can which you can visit and over in Belfast you've got HMS Caroline which actually exchanged shots with most of the high seas fleet at the Battle of Joplin in 1916 which is now open as a museum ship in in in in Belfast so I hope for this afternoon I've just given you a little overview of what sort of what is what you might call the heritage aspects of what happened in the years directly following the armistice and if people are interested in following up a more detail um if I may excuse just to sort of to promote promote this volume which should be out in the spring thank you very much for your attention


Reimagining education means going beyond formal education to provide lifelong opportunities for personal and professional developments. The Lifelong Learning Award recognizes initiatives that create impact and provide opportunities for this to happen. Delft University of Technology wins silver for reimagining the educational needs of healthcare professionals in low and middle-income countries. Realizing that good healthcare provision requires rigorous and innovative training, the Medical Technology portfolio equips professionals to tackle pressing healthcare challenges by providing knowledge based on the latest research and applications, ultimately helping them to save lives. Congratulations to all the winners and remember never stop innovating.