All right, so for those who don't know me, my name is Jim Bell, and we can go on and get started with the second part of today, and I was going to present a young boy that I saw as a consult on the pediatric ophthalmology service, so we'll go on and dive right in. This was an eight-year-old, previously healthy boy who came to the primary children's ER with complaints of malaise, fever, sore throat, and a stiff neck. He just wasn't feeling good in general. He had been seen by his pediatrician a few days before. We don't have too much in the way of records of what happened that day, but he did have a rapid strep test that day and ended up being diagnosed with otitis media with a cephalosporin started. Needless to say, he did end up in the ER, so he didn't feel completely better. He started feeling a lot worse. His main symptom was fatigue, and even when I saw him, which wasn't for a few days, this was still the main thing that he was complaining of. He just kept talking about how tired he was. But he also had vomiting, decreased appetite, decreased fluid intake, and urine output. He had a mild cough that his parents noted that wasn't really of too much concern to him. He also had this rash that his parents talked about that a couple days before had started on his torso and spread to his extremities and face within hours, so it moved pretty quickly. It did involve his palms of his hands and soles of his feet, and by the time he was actually admitted, it had mostly resolved, so it had moved quickly and started going away pretty quickly as well. In addition to everything that I just mentioned, his parents said that the first day of his symptoms, the day that he went to his pediatrician, he had some red eyes. The next day, he actually complained of some eye discomfort and some photophobia, although he didn't think at any point that his actual visual acuity had changed. He didn't think that he had any color vision abnormalities. And he also was pretty articulate and pretty forthcoming with his symptoms. And he said that this eye pain really was worst on the second day of his illness and had slowly been getting better ever since. Other history for him, he had some asthma and really not too much else. Never had surgery, no eye problems. His family history didn't reveal any childhood illnesses for anyone else in the family. He lived locally with his family. They have a few pets, including a bird at home. Both of his parents smoke, no known sick contacts. He just started third grade. He'd never traveled outside the country and there were no known tick bites or insect bites or anything of that sort. Doesn't take any home medications and no known drug allergies. Review systems brought up a few other things. I think I mentioned before he had a sore throat and a sore neck at the start of his illness. He'd also had diarrhea and chest pain and his parents thought he looked jaundiced up until the point of admission. And by the time I saw him, that had also started to resolve. But the notes indicated that he was in fact jaundiced at the time of his admission. So day one when he came into the ER, his first set of vital signs included a temperature of 37.6. That actually wasn't the best example for me to include. I just went with the first temperature they recorded. But the truth was most of his temperatures that were recorded the first few days of his admission were over 38. So he was running a consistent fever at admission. He also had a heart rate of 109 and a blood pressure of 80 over 43, which for an eight year old, those are abnormal. I know that the normal range tends to vary for different age groups. But those are certainly abnormal and were concerning enough that he was actually sent to the unit. He didn't actually go to the floor. He also was extremely drowsy, but still responsive to questions. He had cracked lips, a strawberry tongue. And then the description of his rash was a generalized erythematous, coalescing rash, most prominent on the trunk and inguinal region with involvement of both arms and both legs. And this was the rash that the parents thought was much better than it was a couple days before he came in. So the differential at this point, when you type in differential diagnosis to Google images, house MD comes up. And so I thought I should include him. The differential at this point includes strep and staff toxin mediated diseases like scarlet fever and toxic shock syndrome, Kawasaki diseases on the list, viral etiologies such as adenovirus and enterovirus and even measles were considered. A drug reaction would fit the description, but he wasn't taking any medicines at home, so it's bumped pretty far down the list. And then a lot of autoimmune diseases and inflammatory diseases like Ryder syndrome, inflammatory bowel disease, et cetera. Interestingly, I recently learned that Dr. Ryder, people are sort of looking into his past now. I guess he was potentially involved in some inhumane experimentation in Nazi Germany. So there's a movement to take his name away from reactive arthritis. So I threw both names up there just because I don't think the verdict's quite out on that story yet, but a little side note there. So out of these, the highest on the differential for this patient were scarlet fever, toxic shock syndrome, and Kawasaki disease. Like I mentioned, drug reaction would have been up there, but he wasn't taking any drugs. So that doesn't really make any sense. But the other two really fit with all of his physical exam findings. And there wasn't a great way to distinguish between them. And labs were still trickling back, so they didn't have a perfect picture of what was going on yet. To give you an idea of what he was being treated with, it started with Cephtriaxone, clindamycin, and naphthalene. This treatment regimen changed throughout the course of his admission. But consistent for most of the admission was that he was on clindamycin with the thought that that would treat any toxins that he might have been exposed to. And usually there was something that would treat grand positives like stab and strep. He also, with the thought of Kawasaki disease, was put on IVIG and high-dose aspirin because people just weren't sure exactly what was causing his problems yet. He was sent to the unit and was put on pressers and given fluid boluses because his pressures just kept staying too low for him. And he was having evidence of end organ damage. But eventually he did respond to them while he was on this thorough treatment regimen and was sent back to the floor because he was doing a little bit better. Once he was sent to the floor, ophthalmology was consulted because he was a little more with it and communicative. Said that he was still having some of this eye pain. So they wanted our input. They also wanted our input because they thought maybe we could help them making a final diagnosis and differentiating between these diseases on the differential. So he was a real trooper and actually came to clinic. So I could look at him at the Slotlamp exam even though he didn't feel good. And I'm glad he did because I think we got a lot more information from this visit than I would have at the bedside. Visual acuity was excellent in both eyes about 2015. Both color vision was five out of seven in the right, six out of seven in the left. His pressures, extracular motility, visual fields were all normal. He didn't have an apparent pupillary defect. But then when we took a closer look, he actually had no congenitival injection. He had a little bit of icturus consistent with the previous jaundice that had been described. But he also had two plus cell in his interior chambers in both eyes. His cornea showed no subapithelial infiltrates. Iris showed no posterior synechia, and he did not have cataracts. But there was cell in the interior chamber. He was dilated, and he actually had stage two dyscadema in both eyes. The right eye looked a little more affected than the left, but they were both stage two. Macula, vessels, and periphery all looked normal. And he had about half plus cell in the vitreous in both eyes. So before I get down to what this implies for his diagnosis, labs had been trickling back throughout the course of his admission. So I'm not going to go through each and every single one of these, but the general gist of it is he did have an impressive leukocytosis. A number of viral cultures and PCRs had come back, including Epstein-Barr virus influenza, lots of them. They were all negative. His CSF showed an elevated white count, but really the other parameters in that were normal. So it was sort of a non-specific inflammatory picture. Blood cultures for bacteria didn't grow anything. Again, a number of more viruses here that all came back negative. He also had an elevated ESR on day one of his admission at 45, which jumped up to 107 by the time he was on the last day of his unit stay. But at that point he started feeling better, like I mentioned, so they sent him to the floor. So at any rate, with all of that information, we go back to our differential, the top things on the list of the differential, and out of Kawasaki disease, scarlet fever and toxic shock syndrome, only Kawasaki disease is known to be associated with the uveitis, so that really helped with the diagnosis and the primary team kind of honed in on it at that point, so that was kind of neat. As far as what to do with his eyes, we started prednisolone eight times a day in both eyes, and he was to follow Dr. Vitale in a week. So during this stay, the first couple days, he did have an echocardiogram, because as a lot of you know, Kawasaki disease is associated with coronary artery aneurysms, and this didn't show anything, which doesn't rule out Kawasaki disease, but it doesn't help make the diagnosis either. And then, like I said, he was started on IVIG and high-dose aspirin, this was continued after I had seen him in the clinic, but eight days after the first one, he did develop coronary artery aneurysms that were seen on a repeat echo, so this happened while he was in the hospital, unfortunately, and the entire purpose of giving those drugs is to keep these artery aneurysms from forming, so I'll talk a little bit about that later in the talk. So he came back to see Dr. Vitale, he'd been taking the prednisolone as requested. Vision was still great, the interior chamber cell had improved, but not completely resolved, and the same was true with the vitreous cell and the dysphedema, so he was moving in the right direction, but not totally back to normal yet. He said that his eyes felt normal, and he was happy with where he was. The plan at that point was to taper the prednisolone and have him come back in a month or two to see how he was doing. So a little bit about Kawasaki disease now, it's a vasculitis mediated by IGA, and it affects small and medium-sized vessels by causing fibrinoid necrosis in the vessel wall, so this doesn't limit it to just the coronary arteries, but that's where the most common and most serious complications of the disease occur, which is why that's what we always think about, but it happens in vessels throughout the entire body. The coronary, like I said, the coronary arteries are most commonly affected. It happens more commonly in boys than girls, and more commonly in young kids under five years old, which is partly what the hangup was with our patient, because eight years old is a little old on the spectrum of people who get this disease and they just didn't want to miss something like a toxic shock syndrome that could be potentially fatal. So how do you make the diagnosis? All these children, in theory, should have a fever for five days. I think that they sort of trusted that the parents felt that he had a fever for all those days prior to his admission, because his fever actually did continue after he was admitted for over five days, now that I think about it. You also need peripheral extremity, perineal area changes, like swelling, scaling, palmar sole erythema, our patient did have that. He had the rash that reached the palms and soles. He also, the day that I saw him develop swelling of his hands, and that's another point with this, is that not all these findings need to be present on day one, you can develop them as time goes on. So even though they don't quite qualify for Kawasaki disease right away, it should still be in the back of your mind because they might qualify in two or three days. A polymorphous exanthema, which our patient did have, bilateral conjunctival injection, our patient had that as well, and then a strawberry tongue. So our patient had this, and then the fifth one our patient didn't have actually. He didn't have cervical and fat anopathy, but he did have four out of the five in addition to the fever. So a little bit more about the conjunctival injection. It's extremely common in these patients. Over 90% of the patients do have it, and it is bilateral. So because it's so common, it's not something ophthalmology typically gets consulted for because it's a known finding in this disease. But if it is present, and you do see the patient, it should just be the bulbar region, the palpebral conjunctiva should not be involved, and there should not be chemosis papillae follicles or discharge. If any of those are present, you should start thinking about other illnesses such as, for instance, adenoviral conjunctivitis, with which I am very familiar, as some of you know. So that can make people feel awful. It can give them fevers. It can just make them feel terrible. It can give them a rash. It can give them cervical and fat anopathy. So that can cloud the picture too. And that's something that you can be of help to for a primary team. If the patient has this really nasty discharge from their conjunctivitis, you might want to steer them away from Kawasaki disease. It often resolves as well within days of IVIG treatment, which may be the reason that I didn't see any of this injection the day that I saw the patient, because he'd already been treated for a few days. So what about the interior uveitis that I saw? There were a few studies that I came across looking at a series of children with Kawasaki disease and the incidence of the uveitis. And one of the studies looked at 41 patients with Kawasaki disease. All of these patients were examined at the slit lamp, which I thought was impressive since you're talking about young children. And the timing of the exam was measured with respect to the onset of the fever. So the first day of a recorded fever was day one and so on. Exams were positive only if the patient had cell or flare in the anterior chamber. So out of these 41 patients, 27 were found to have interior uveitis. I thought that number was really high compared to what I anticipated seeing. Out of the 27, 25 had bilateral involvement. 24 of these patients had their first slit lamp exam within one week of the onset of fevers and 20 out of those 24 had a positive exam for anterior uveitis. If you looked at the rest of the patients, there's 17 patients left who weren't examined until after week one. Seven out of those 17 had a positive exam for anterior uveitis. So the p-value for the difference between those two groups was 0.004. That's a huge difference for finding cell in the interior chamber from week one to week two. So that would potentially imply that a lot of these patients have this reaction that's going right away and then it kind of resolves on its own. Especially since most of these patients didn't actually complain of any eye problems. They didn't have eye pain. They didn't have vision changes. They just were examined because it was part of this study. So it's kind of interesting. A lot of these patients might actually have these reactions and we just don't know about it. While the timing of the exam did seem to correlate with the rate of positive exam, gender, age, race, ESR, ESR value, and aneurysm formation didn't correlate at all with whether or not an exam for anterior uveitis was positive. So the only indicator of whether or not you were gonna find this seemed to just be the timing of the exam with respect to the onset of fever. So there was another study that was somewhat similar in setup. It looked at 115 Brazilian patients diagnosed with Kawasaki disease. This study was a little more general. They involved ophthalmologists to look for anterior uveitis but they were looking at other aspects of the disease as well. All of these patients were treated with IVIG right when the diagnosis was made and all of them received a slit-lamp exam and dilated fundus exam. These eye exams were performed in the acute and subacute phases of the disease and in this study, only 15 out of 115 patients actually had ocular manifestations of disease with 13 of those being anterior uveitis. All of these findings resolved within 30 days of the first eye exam. So this is a really different number than that first study and there were three things that I could come up with that were different between the two. These were the two largest studies I came across regarding uveitis and Kawasaki disease. One was this study was primarily Brazilian patients so there could be a difference in the manifestations of disease depending on the patient's ethnic background. Another was all of these patients were just received IVIG treatment whereas they didn't imply that in the other studies. So if not all those kids were getting IVIG treatment it might have affected whether or not they developed this uveitis. And finally, this study, all of the exams were done in the acute and subacute phases but they didn't really define what those were. So I don't know how early they were actually having their exams and if they were all having them week two, week three then that would imply from the first studies results that these numbers are gonna be a little bit lower. At any rate, I think the take home point from these two studies is that anterior uveitis is associated with Kawasaki disease and even if you go with this lower number of 13 out of 115 patients it's still a significant number of patients and it's still something to consider for these kids. So I talked a lot about the anterior uveitis but our patient had dyscadema so what to make of that? There was a case report that I came across of a six year old boy with Kawasaki disease. He was admitted and started on IVIG. Day two of admission he had eye pain so he had an ophthalmology consultation. This is actually a picture of his eye. They found punctate epithelial keratopathy endothelial precipitates, macular edema, periphoveal, stellate exudates, horizontal rednal folds along with cotton wool spots so they found a lot of stuff going on in the back of his eyes. These are his OCTs which revealed macular edema, sub-phovial detachment of the RPE and exudates in the outer nuclear layer that were consistent with that stellate pattern you saw in the color photograph. They started him on local and systemic steroids and his vision was excellent along with a normal OCT within two weeks of starting that treatment regimen. So he, like our patients, seemed to rebound quite well as far as his eyes were concerned once he was on some steroid treatment. They sort of reviewed the literature and I looked at a few of these papers and the general gist of posterior involvement in these uveitic processes is that they're not reported often but it's not entirely clear if they're not reported often because they don't occur often or if they're not reported often just because most kids don't have an exam. If you'll recall, most of these patients from the first studies that were done really don't have any ocular complaints and they all have red eyes but that's the known finding in the disease so there's no reason to have them at a slow end just for that reason. So this could happen more often than we think. This patient had an exam because he did have eye complaints but it's really hard to sort of tease out the frequency of these findings in these patients. So posterior segment findings listed in the literature include optic disc edema, vitritus, perivascular sheeting, optic disc vessel leakage, arterial or narrowing, stellate maculopathy, and macular edema. So those have all been recorded but like I said, the frequency is pretty much unknown. So I keep talking about these kids who have all these findings that get better and no problems really occur but that's not always the case. There was a nine-year-old girl in the literature who was admitted with Kawasaki disease. She was started on IVIG and P.O. aspirin. Day two of admission, she said that she went blind in her right eye on exam. She was found to be no light perception in the right eye with normal vision in the left.  Dilated exam showed a quiet vitrious in a normal left eye dilated exam but her right retina was white with a pale edematous disc, narrowed arterials and no cherry red spots. So with all of that, especially the no cherry red spot, you'd think of an ophthalmic artery occlusion which was in fact what her final diagnosis was and in spite of prolonged treatment she didn't improve at all. So I included this story just because I thought it was important to illustrate that if you have one of these kids, it's not necessarily that it's UVitis that's bothering them with their vision. This is at heart a vasculitis that affects the whole body and can certainly affect the eyes through the vasculated component and can lead to things like emboli and thrombi that would occlude arteries that are essential for the function of the eye. So keep lots of things in the back of your mind if you're examining a kid with Kawasaki disease who has ocular complaints because it might not be a benign finding like all of these other stories that I'm presenting today. So to sort of close with the final report there was an 18-year-old woman and I thought this was interesting. I don't have any statistics on this but all of these case reports involved children including the story that I gave who are older than that normal age range of five years older or younger. So I don't know if that means something or if those are just the kids who cooperated with the Slotlamp exam but the children who seem to have vision problems or eye pain all seem to be older than the normal age range for Kawasaki disease. This patient had decreased vision, fever for a week, strawberry tongue, erythematous macules. She qualified for Kawasaki disease but she also qualified perfectly well for scarlet fever and toxic shock syndrome. So it was really interesting. I included this because this differential was exactly the same one that we had for our patient. The only difference was they threw in a drug reaction because she had been taking medications at home. So I don't think that it's an isolated incident that we have this patient at Primary Children's who had that very list of diseases on his differential. This patient was given almost the same antibiotics along with IVIG and aspirin and ophthalmology was consulted to help out with making a diagnosis. So before I go through what they found at the Slotlamp, why do they care? What difference does it make? Well, there are serious implications with Kawasaki disease. The most common of which, like I mentioned, was coronary artery changes. They don't have to just be aneurysms. Stenosis can happen as well. 15 to 25% depending on which paper you look at develop these coronary artery changes and out of those patients there's a 2% mortality rate. So there's not a huge mortality rate but it's certainly there. And if you're talking about someone's child, I think that's something to really consider. It's been found that treating with aspirin and IVIG can help decrease the rate of the formation of these aneurysms and decrease the rate of death if these aneurysms are formed. The rate of coronary artery change decreases by three to 8% and out of those patients, mortality decreases to 0.2% if you give this treatment. That all sounds great but if you really look at the numbers that's not a huge change. You're growing from 2% of 20% of the patients to 0.2% of say 15% of patients which isn't, it's a pretty large number needed to treat when you really break it down. But it is a real difference and if it were my child I would probably want them to receive this treatment which is why all these kids get it. As you recall, our patient had IVIG and aspirin treatment and still developed the coronary artery aneurysms. So it didn't stop him from developing these changes but after a few more kids you might have actually prevented this from happening. As I mentioned before, these aneurysms can occur in other systems in the body including the GI system and the central nervous system. So it's not just the heart that you have to be worried about but that is the most common location for these changes to occur. So back to this 18-year-old girl she had numerous findings of UBI as conjunctival injection, keratic precipitates cell in the anterior chamber. She didn't have a visual acuity measured because like our patient she was extremely tired and it sounds like she couldn't sit up for more than just a slow length exam. Kawasaki disease was the diagnosis, aspirin and IVIG were given and she responded very well and was discharged and did well afterward. So back to our patient, the final bit of the story. He was started on three days of IV methylprednisolone followed by steroid taper. Rheumatology was working closely with him and felt that since he developed these aneurysms while on IVIG they wanted to be more aggressive with his treatment. He still had fevers throughout this whole time. I mean he really didn't feel good for a long time when he was in the hospital. So they gave him infliximab which seemed to have the fevers resolved so he was discharged and then unfortunately came back the very next day with a recurrent fever. So they still hadn't kicked this thing. He was admitted to rheumatology at that point and he got another round of high-dose steroids and he did quite well on those and went home afterward. So the plan is he's still supposed to follow with Dr. Vitale in the next couple of weeks I think. Dr. Vitale is out of town right now but I'm interested to hear how he's doing when he sees him again. So I think the take home points from this is that UVitis is pretty common for patients with Kalisaki disease and it seems to be fairly self-limited. Our patient and a number of the other patients that I talked about did have steroid treatment for the UVitis but if you think about it those series of patients, most of those kids would have developed UVitis and never had any treatment because they wouldn't have had an eye exam because they didn't have complaints. And most kids with UVitis don't end up with poor vision down the road. I would think that it doesn't really typically have long-term implications for patients' vision. It's often but not always limited to anterior UVitis and then serious sequelae of the disease are possible if you remember the nine-year-old girl with the ophthalmic artery occlusion. So just because I keep saying the UVitis seems to get better, their eye complaints might not be related to UVitis. This disease can manifest in different ways so they deserve an eye exam I think if they're having eye problems. The presence or absence of UVitis can also help the primary team clinch a diagnosis which seems to have happened before our case so that's something also to consider and it's kind of fun to be a part of that. So that was, or any questions? I don't think they actually measured that. Did I include, I don't think that they measured it. I don't think they measured it actually. I could go back and look but we interpreted that more as a breakdown of the endothelial barrier as part of the vascular process. That's a good question and maybe we should have considered that more but yeah, we interpreted it as more of a vascular process than a high intracranial pressure in part just because it had been reported a few times before and it seemed to fit with the rest of the picture. I don't think there is total conclusion on that. If anyone out there disagrees with me, please let me know but I didn't come across any real great evidence of the way that it did work. I think the thought is that it helps with the inflammation but I don't think people know for sure. They found that it helps. Does anyone know more about the mechanism there? I don't think they're limited as far as what they're allowed to do as a child but as far as what that means for when they're 50. So there are thoughts along with Dr. Cass's giant cell arthritis work. There are thoughts that this could be related to an infection and no one has proven that. They don't know what bug would cause it but they think that these children might be exposed to some sort of a pathogen and have a setup where they are susceptible to an inflammatory change related to that pathogen that people haven't isolated any specific disease to cause them that. That's the leading theory out there but it hasn't been proven. No, they're not standard of care. So they were given for this patient and I didn't come across them making things worse either so I don't know if that's true but they're definitely not standard of care. The standard is the IVIG and Aspen treatment. Our patient got that and continued to get worse and I think rheumatology was kind of reaching for things because it wasn't just that he developed these coronary artery aneurysms it was also that his ESR continued to be high. He continued to have fevers.  But the other indicators that people were going by with him was that he just wasn't getting much better so I think they were reaching for things and giving treatments a little bit outside the box with him including the influx of mad that he eventually got. But no, it's not standard of care.


Hello and welcome back to another Premiere Pro tutorial. This one, we're working with audio. I'm gonna show you how to make audio go from one speaker to another speaker. So from your left speaker to your right speaker or your right to your left and then to both. This is called panning and it's easy to do and it's very commonly used, especially in a lot of audio and a lot of songs actually ramble on by Led Zeppelin. There's a whole bunch of friggin' Jimi Hendrix songs that used it. Let me show you an example here. I'll hit spacebar and you can hear what it sounds like. In this video, I'm gonna show you how to make audio go from one speaker to the other speaker and back. Did you hear that? It went from both speakers to the right speaker to the left speaker. How did I do it? Very easy. Let's start from scratch. I'm just gonna go ahead and I've got some footage in the timeline. I'm just gonna drag and drop some audio in and presto. We've got our audio. There's been no effects applied to it.  You open up Panner, you're gonna see Pan. It already has a stopwatch or a toggle animation applied to it. So just keep drilling down on it and you're gonna see that it's default set to zero. That's what we want. Okay, good. The first step is I'm just gonna go ahead and add a key frame. So this is gonna basically set a zero key frame. So I'm adding a key frame and you'll see the little diamond head there. And then that's, so for the first bit, I'm gonna go to about two seconds. And then at the two second mark, I want it to pan to one of my speakers. I want it to pan to the left speaker. So what am I gonna do?  That means it's entirely in that one speaker. Let's hear what that sounds like. In this video, I'm gonna show you how to make audio go from. So now it's entirely in the left speaker. Let's say I don't want that anymore. I wanna make it go to the right speaker now. I'm gonna add another key frame right here. And then I'm gonna go forward. Let's say a couple seconds and then I'm gonna go all the way to the right. And you can see here in this little graph that you'll see that is going up, down and this is basically selecting which speaker. So let's see what that sounds like. Audio go from one speaker to the other speaker and back. Now it's only in the right speaker. That's how you do it. If you want it to go back now to the middle, you can just click on that button, bring it back to zero and it will be now both speakers equal. That's all there is to it guys. That's how you pan. That's how you move from left headphone to right headphone left speaker to right speaker and vice versa. Thanks for watching. Ton more stuff coming up. Stay tuned.


The objective of this workshop is to bring in to you the CELBE. We want to give you an overview of the CELBE system, the software development environments and the CELT SDK 2.0. And then we will talk about the CELT BE software model and application code, how to report applications over from a regular traditional architectures to its CELT architecture. We also really want to go out with you and show you how to write the programs under the CELBE. Just affecting a very similar program and how do we convert the program into a CELT program. What is the difference? We will point out the differences also. We will point out the key difference between these architectures and other architectures. The vectorizing, the SIMD, SIM instruction, multiple data stream, which is the main features of this architecture. We go through all those vectorizing, exercise, and then we will show you the different kinds of tools that we have. Development tools. The integrated development environment for the SCF, we call the IDE, which is Eclipse-based. The SPU timing analysis. Some of the performance tools that allow you to look at and to analyze the performance behavior of the system. And also some of the tools that we have on the SDK 2.0, which we call the Feedback Directed Restructure Program, FDPR Pro. So you can input just a binary of your code. And then the programs can go through the exercise, analyze your programs. And ask you, run the program the first time and give me some data. And then using that data, I will optimize your program by restructuring your program. So this is a little bit different than some of the tools that we had before from the open source, like the VPA, we call them Visual Performance Analyzer. The VPA or Visual Performance Analyzer just analyze your binary code only, but not optimizing or restructuring the code. The FDPR will restructuring the code for you. And then we look at some all profiles. All profiles is in open source, two available under the Linux distro. This is the system software enablement that we have since 2005. As you see, the timeline over here, 2005, we released some SDK, SDK 1.0 with 1.1. We support the Singapore. We support the board bring up at the time, right? And then we integrate the board into a system. We call it the cell plate. And we integrate that cell plate into the cell plate chassis so we can form a server. And then we can, you know, talk about the clustering. By the end of last year, I mean, then we talked about things that you can have a cell product engine, right? And here, in some other cell plate, can we run a traditional CPU, for example, an opteron, right? Or an Intel-based system. And let those systems talk into the cell here, right? And since you guys perform a very specific function, computational very fast, extremely fast, are very exceptionally fast. Then we talk to each other and use you to cell BAs and accelerators, right? So this project here, the Los Alamos National Labs, we, the IBM signed up with these labs here, provide about 16,000 of these, the cell BAs and 16,000 of the AMD opterons, connect to whole clustering, right? So we form a very, very large computer system, offer that there are flops and large number of flops, whatever. So that's what the movement of the progression of the software from the beginning, supporting a single board bring up to the system and now to the whole world, the clustering world. Here's the progression of the SDK. SDK, as of now, we have the SDK 2.0. And then since we released SDK 1.0 here to support our board bring up and the base of the cell plate. And then now we have removed it to SDK 2.0, which provide a full blown of the XFC compilers. This is the IBM compilers. We're also working with the new open source here, provided a GCC compiler. So we have the two compilers available all the times on the cell BAs here. We also have Linux kernel working with Linux kernel teams from the IBM labs in Germany so that we can and also in Australia to provide a fix and patches. So we bring in the mainstream of Linux 2.6.18, which is loading with the base kernels for the running on the cell plate. And that is also the basis of the main. So you have an IDE here. You have a performance analysis tools. You also have the MAMBO, which is the simulator. This is an IBM simulator that was used to simulate the Power 3, Power 4, Power 5, Power 6. This is not a new simulator, but it's an existing simulator has been proven and been used by IBM to simulate hardware when we develop a new hardware. We should ship the simulator with the SDK 2.0 so we can use the simulator to write the application and compile and run on simulator. And this SDK 2.0 running on different platforms, the FC5, Linux 8.6, Linux Unsell, and also Linux on Power. This is Linux base FC5. This is the cell-based systems, cell-based stack. We have the applications working with the ISV and universities and different labs around the world. And some sector-specific libraries for the sector application sector like AMD, aerospace and defense, financial sector, and also some other sector like the exploration and so on. And we also have, going that, we have the tools, environment, the compilers, the libraries, operating systems, and so on. This is the left of the software stock provided by IBM and some of its partners. And also these are the kind of basic features that we put into SDK 2.0. Overlay support, accelerator, library framework, ALF, performance tooling, all profiles and so on. Now this is the roadmap from the hardware point of view. 2006, the CELBE we released, officially released, right? And made it available, commercially available for you to purchase the system. We can integrate it in the cell plate and the cell plate chassis. So we can form a clustering of those guys. Now we have this, so 2006 we released the CELBE, which is a 1PPE and 8SPE. We call nine of them using the process of 90 nanometers SOI, silicon on insulators. Thank you very much. I never remember these guys. SOI, SOI. And then in 2008, we're working on now, we continue working on, hopefully, not hopefully, but we will release in 2008 a version of what we call enhanced BE, which has improvement performance in the double precision. Okay? And then by 2010, we released another processor. By that time, we reduced the size using the 45 nanometers SOI and then one teraflops processor. This guy is running about 200 gigaflops performance, you know. So this one, like a five times improvement in terms of performance. And then you're reducing the size, half the size, cut in half the size of the chipset. In terms of software, we released SDK to promote in 2006. This is running on two CELBE processor here and single precision floating point affinity. Extremely high performance on single precision floating point, one gigabyte of memories, 500 and 12 megabytes for each processor. We connect both of them together. We form a system or a board with two processors. Two processors means two processors here mean that you have two PPEs and 16 SP. So you have a system on the same board with about 18 cores. We call it 18 cores, 18 CPUs. And then we move on SDK to promote, just release, advance some CELBE here by 2007. And then we improve the memory here from one gigabyte of memory to two gigabyte of memory. And we support 16X, 16 times the PCI Express card. By the time of 2008, we will provide some support for the double precision performance, improve that one from what we have now into almost double, right? And then we support up to 16 gigabyte of memory. So for those applications that require a lot of memory, a lot of memories, and this is the times, for example, Java and some other applications, that's required. You have to make the memories available and stay resident into system memories, for example. We will provide some system by 2008 to satisfy those requirements. Okay, where to get the CELBE information? You have a lot of places to go. IBM spread out a lot of information. The key site is the CELBE Resource Center at Developer Works. Okay, we call it the Developer Works. CELBE Power Zone and slash CELBE. And then we also maintain what we call some CELBE corners at the Power.org, the CELBE Project IBM Research and so on, the Alpha Works and so on. Okay, and then for the CELBE Education, we maintain a website in which we can download some of the materials and, you know, we can download all the materials. Anyway, all those are available to you to the public and you want to know what's going on, so we can go up here and download the files in there. We have online courses, IBM learnings. We are on the process of putting a lot of our courses, such as these courses on the IBM learnings. So this will be made available to the public as well. We have podcasts at Power.org and on-site classes at various IBM Innovation Center. Documentation. And here I have a list of documentations with respect to the self-portment engine, a list of them, the architecture, programming handbook and registers and extension of the C and C++ to support the SPU. And then, you know, the SPU description, instruction set architecture, the ISA and abbreviations and the SPU application binary interface and assembly language. The documentation using the SDK, right, we have an installation guide, a programmer guide and so on. We also have the documentation for the self-play center, the QS20 and then for the compilers and the documentation for the simulator, for the PowerPC base, because one of our systems is based on the PowerPC architecture. And here's a list of technical articles. This is some detailed description here. We get the time you're going through. The key documents that I would like to recommend all of you to read before you do some programming is that the CELBE programming handbook. This book is about 857 pages. It's considered as a CELBE cookbook, right? Description, everything. So you need to know programming, you need to know architecture, you need to know anything about it. Just come there. Don't print, okay? Because to print that one, you kill a lot of trees.  Okay? Let's move on. Developer works here, architecture. This is just a detailed description of what I just described on the other pages previously. We maintain some information at the Barcelona Supercomputing Center. We call it the BCS. This is why we maintain this one. On this side, we maintain all of the open source software. GNU, compilers, the fix and patches for our Linux kernel, installation scripts, all of those, and the Linux tunes and GNU tunes, we maintain those at the BCS because those at the open source and public and IBM don't want to get involved into this area. Okay? Let me talk about CELBE and give you an introduction. Here, I will have a lot of pages. I will cut it short because we're short of time, and then just an introduction.  Okay? Overview of the CELBE history, microprocessor highlights, hardware components. So environment, this is the objectives in this presentation here. And then this is an agenda. So history-wise, IBM, Sony, and Toshiba, Jean Force in 2000. And by 2001, coming up with something like, okay, let's pick up a site which is also inside, right? Texas, Texas right here. And then we first formed, you know, the first single CELBE operation in the spring 2004, two SMP, come up in the summer, and then six CELBE released a different release here, especially, you know, the CELBE plate was announced by IBM in February 2008, 2006. SDK 1.1 was made available in July 2006, and then the G8 of IBM Place Center, TQS 20 in September 2006, and the SDK 2.0 available in 2006. 2006 marks a very, very special year for IBM in terms of releasing the products and make the products become commercially available, okay? And here's the location of those labs that are working on the cell, right? So we have it in North America here, we have it in Europe, in Germany, some place over here, and we have a large lab also in India as well, okay? This is the size of the cell processor, right? There's a push pins, okay, and then there's a small ASI socket. This lady here has a very small ASI socket, so we use that one. Otherwise, a larger than half mile, we're not going to use her ASI socket anyway, right? Okay, basic design. We have, as we're moving on, you know, form processor design and different architecture and so on. Among the other things like the course, the times, we recognize the three gating factors that inhibit our design. The first thing is the power, power dissipation, power consumption of the processor. The second one is the memory. As we move the data, and we design the processor to support the movement of the data, always make sure we have the data available when we need it. We create a memory hierarchy, different memory like our CPU. We choose the level one, level two, level three, cache and so on. By doing that, we make the... If everything is okay, we're okay. But if we're missing something, if something happens, the data is not there, and we have to fetch the data, we have to flush the cache, we have to do some other extra tasks, so that we can bring the data in. That's causing great latency time. On the power five, we look at 75 cycles, 150 cycles, if we have a branch miss. So we look at the power, we look at the memory, and we look at the frequency. We cannot bring up the frequencies as high as... greater than 3.2 gigahertz, 4 gigahertz and 4.5 and 6. You saw the history, if you look back a couple of years, about five years ago, we have an Intel AMD coming up with 2.4 gigahertz new encore, 2.6, 2.8. They're not going up to 3 or above 3 or so on, because they cannot control. This is a reverse or what we call the inverse relationship.  You have to switch faster to obtain the frequency, the higher frequency, and switching to get faster, generate more power. And we look at this one here from the IEEE descriptions, a publication about... I think it's 2001, and we look at different processes over here and the frequency, and we support like 1 gigahertz, we see the couple of materials here, then the SOI materials, and then the low-cave dielectrics and so on. And all of those has been used, materials used to support the higher frequency. Now, more laws, of course, two extra systems density every 18 and 24 months, but more law did not say that the power dissipation of the power consumption of those gates will rise as well. So he talked about the number of transistors, he increased transistors, transistors consist of gates. And then those gates switches consume power. And some of the gates, they also produce power, they consume power even when they're inactive. So we have active gates consume power, inactive gates also consume power. So by adding up a lot of power that we generate. We know how to design the processor, but we do not know how to control the power. That's the key point here. Where the transistor gone, right? This is key from the first date, about 10 years, 15 years ago, when IBM created the first PC, the first CPU, very simple. There's 64 kb memory only, no level cache, no level 2 cache, nothing. There's no virtual memory support. There's no superscalar micro architecture and so on. Then, and now we introduced like the CPU, the cache, the layers, we introduced the micro architecture superscalar to support more units, the deep pipelines. We look at some of the current architectures, the pipelines like going from 10 stage, 12 stage, like 30 stages with the Intel base. So 30 stage is a lot of stage, right? You may hide some performance here, but you introduce a long delay. If, and then it will cause a lot of real state on your board as well. And we talk about the out-of-order processing. Most of the systems said, okay, give me some instruction, I will decode that instruction, I will bring that instruction in, and the data is on and we can run, right? Now, if something happens, I will leave that one and I will stack up another one, I will get a process. Now, everything is out-of-order, I don't care, okay? But out-of-order support is very expensive as well, okay? And here is the chart we discussed about the lithography improvements, increase the cache size, deep pipelines, superscalar, out-of-order processing, and the trading. All of those techniques were used by various microprocessor designers to help or to improve performance of the processor. Okay? And here is the chart, this could limit more details on the different memory organization and so on. The key point is here, here is on the chip level multiprocessors, okay? We can, we don't have to go through the traditional design. We can reduce the superscalar, reduce the pipeline depth, reduce the speculation. Instead of out-of-order, we just do it in order. It's easier when instructions bring in, we will bring in an instruction, we call the instruction, get the data, so on, and then we execute that instruction until completion without the out-of-order execution. We also bring up something like we call the SIMD and the vector so we can do a lot of operations in parallel at every cycle. Instead of waiting for the cycle to complete, instead of well vectorizing the instructions so we can bring in a number of elements, processing those elements together. And then different memory organization here. Remember, the basic organization is that when you need to run, to execute some instruction, you get some data, you have to load that data into the registers finally at the end of the food channel, whatever, and you execute it. Why don't you provide a set of registers, you know, instead of having all of those extra steps whatever, providing the set of registers right next to your memory, right? Eliminate all these intermediate steps. Just go straight and form the register and the memories will be called here the local memories. Loading the instruction, your data into the local memories and when it's time to execute those instructions, load into the registers and voila, perform the operations. So we talked about all of these concepts, the basic concepts that we mentioned here is the accelerator hardware, accelerator concepts. And we will accelerate all of the operations and using this board here, providing, you know, let's say that we have a level two cache and if we have a system of memories which are coherence with the level two cache, okay? We maintain the coherency with that level two cache, right? So everything that we do, on the main processor, we do it very fast and however, anything that we do locally on some other satellite processors or remote processors, we can do it together as well and we maintain the coherency so the integrity of the data always maintains throughout our system, okay? And here we say that, all right, now providing some of these features here, we can convince, we can win over the memory wall, frequency wall and the power wall. Providing a very simple set of processors, moving the data, okay, instead of going through a layer, a hierarchy of memory, we go through from the locals, from the memories now to the register right away. And don't make it run fast. We don't need to go through like a four gigahertz or five gigahertz, right? Remaining on some frequency, but we don't look at any more, don't look at the time or execution time, type of unit, type of unit of wall, right? Look at the number of wall, look at the number of transaction completed per unit of time. Look at the throughput, because we provided, you know, a multi-core, a multi-processor system here. You know, each of them go ahead and do something. The throughput is what it's called, right? At the end, how much transaction, how much transaction we complete, that's what it's called. Some other micro-architecture and decision, the last shared register file, local store size, trade-off and so on, those we think we talked about, we can issue two instructions at every cycle, software branch prediction, we remove the hardware support for the software, for the branch prediction and replace that one with the software branch prediction and leave this decision to whether or not we take a branch or not taking the branch to you as a programmer. You, the programmer will have to make a lot of decisions when you program on this environment.  Some of you may say, well, we leave that to the compiler. If not, yes, the compiler will do that as well for you as well. The second steps, it is a base on the 64-bit power. So we build the 64-bit power PC so we can leverage the applications and also the investment that IBM's and the partners have been putting, you know, for the past many, many years. IBM, this is the power trees which went back to like 15 years before, right? And we increase the efficiency and performance and go through a non-homogeneous coherent chips multiprocessor. Okay, we have a night course. We're streaming the data. We provide some sort of mechanism so we can stream the data between components extremely fast. Okay, and then we provide some interface to the outside world, go through some, some the, we call the flex IO connection which allow us to connect either it's a self-processor together to form an SMP system or we're going out to the IO world to collect the data from the IO devices. Okay, hardware components. Let me give you some highlight of the CELBE here. This is the board, all right? And we have about eight SPEs here. Now, if you look at this one, we still dated here, in 1907. So Hemman and I were still in different time zones. So forgive us if we screw up anything, right? We have 20 here. So this is the power-producing elements and this is level one, level two cache, level two cache right here and eight of the SPEs in the element interconnect buzz and so on. Now, this one, this board here consists of about 241 million transistors. The area is about 235 millimeters squared comprised of nine cores and 10 threads. We have the simultaneous multi-threading here on the power-PC. So we actually support the two threads on the power-PC and each of the SPEs is represented by another thread. So we have eight threads for the SPEs and two threads for the PPE total of 10 threads. Simultaneous threading, right? We have a performance single-precision greater than 200 gigaflops and double-precision about 10 times of that one, 10 times less, about 20 gigaflops. Memory bandwidth about 25 gigabytes per second memory and then the IO bandwidth about 75 gigabytes per second. The EIB, which is the one that connects all the elements together running about 300 gigabytes per second. Top frequency is about greater than four gigahertz. Some publications, some technical publications only published on the IBM site and some other conferences mentioned about 5.2 gigahertz. Internet labs were able to achieve the 5.2 gigahertz but here we just release a system with a running at 3.2 gigahertz only. And here is the diagram that described our system. We have a lower portion here. We have a PPE which is a traditional processor. It is based on the 970, which is the power of the Apple G5 but it is not the power of the PC 970. It has some features but most of the features from the 970 was removed, for example, the card support, the French prediction support and some other output support were removed from the 970. And then this one has a level 1, level 2 cache and it supports the VMX, the vector multimedia instructions which is similar to on-the-effects and some other vectors instruction support on the Intel architecture base. In addition to PPE, we also have A-SPE. Each SPE defined by the execution unit, a local store and the memory flow controller we call the MFC. This MFC is very important because this is a hardware base. Each SPE has one. So the flow of traffic and the transfer of data and the traffic flow between the SPE to end between SPE to end to the PPE and between the SPE into memory and to the burst interface controller here which goes to the outside world. They can all be done concurrently and parallel. We are not gating. Our transfer here is not gating by a single MFC but they have individual MFC for each of the SPE here. Very important concepts right here. Here we run up to 96 bytes per cycle 96 bytes per cycle which is translated to about 300 the top maximum bandwidth is about 300 gigabytes per second. Here is the chart describing the cell processor. In the middle here we have the power PC we call the power PPE, level 1, level 2 cache two-way hardware when they trade it level 1 cache, level 2 cache coherent load and store the VMX instruction support running a 3.2 GHz. We also an outside over here we call the SPE APL chips, 100 controller 8-bit wide SIMD units. Outside over here each of the SPE will have about 128 registers. Each register is 100 controller 8-bit wide. What that means? That means that if your instruction is about 32-bit 32-bit instruction. Effect the instructions if your data type is about 32-bit you can have about 4 data elements in that register you can load 4 elements every time. So you can perform 4 operations concurrently in every cycle. If your data type is carter 8-bit you can have like a 16 of them running together. So it's very powerful here. And we also have interconnect right here which connects all the elements together and the description about this is that we can have a greater than 100 outstanding memory records at any given instant of time to go through this EIB here. Memory management. We have the concepts of effective address on the power PC. On this one over here running at the 64-bit address. Each of the SPE here running at the 32-bit address. Support 32-bit address and instructions here at 32-bit instructions. So we have a 64-bit address on the PPE and we have a 32-bit address on the SPE. The memory on the PPE has to be translated now to the SPE as well as the SPE memory address has been translated to 64-bit address if we want to run some 64-bit programs on the PPE. All of those translation and memory management are performed by the MFC with the MMU units here. And all of the SPE-DMA access that means that the data transferring between those two will be protected by the MFC and MMU. When you do memory transfer, you go through this MFC. Excellent connection. We have 25.6 gigabytes per second bandwidth here and we have two connections here. One is for connecting the processor together. The other one is connecting the IO device to the SPE. Synergy. Cell is not a single processor. Let's say it's a non-homogeneous multi-core system and each of them perform a very specific function. The open system running on this one is Linux. Linux is a different version of Linux distro. Fedora Core 5. We also seen that on this one over here, I run the Yellow Dog. I also can run Debian. I can run Ubuntu. I can run any so far, any Linux version. That one, that version, that Linux will run on the PPE. On the SPE, it's dedicated just for computational only. So, very clear distension between the two. Do we do any scheduling? Do we do any timing tasks and so on? Down the SPE? No. Everything we learn on the PPE only. The software environment, we provide some for development environments. On the left side, the tunes and the debug and performance tunes and so on. Mr. Ronyasun, those guys that you've seen before. On the right hand, we have a sample workload, ship in your SDK and SPE management libraries so we can manage the SPE, create an SPE, queue an SPE, release an SPE and so on, create an SPE group, for example. We have Linux PowerPC 64 with cell extensions that you can go to run on the SELB-E here. Verification hypervisor, supported by the PowerPC and the hardware system level simulator which used to develop your code and the language extension API. The system simulator, this is the simulator we talked about. The Pascal of Slice. This is an overview of the simulator. Here we have a two-use interface for the simulator. We have a command line interface and we have a GUI interface for the simulator. As a programmer, when you bring up the simulator, this simulator will boot a Linux version. This is 2.18, 2.6.18. That Linux version represents a fully implemented Linux version on the cell. Now, on the native system, you of course don't have a simulator. This simulator exists only if you do your growth developments using the x86 base as the growth development platform.  This is what's provided in here. Have a different simulator environment. We go more details on this. This is some shots. Let me go back here a little bit too fast. When you bring up, this is the GUI interface for the simulator. On your left side, you have the resources of the cell. Here, we describe only two power PC, PPC0 and PPC1. And then eight SPU. On the right-hand side, you have the control of the simulator where you issue some commands to control the execution, running, stopping, collection of data and so on. Here's the simulator environment. In this window here, when you bring the simulator up, it will move to Linux and display in this window. We call it the simulated window. And some of the data that you can look at from the statistical point of view or from the resource point of view. You can set a break point. This is some graphic, nice graphic. You can see that one as well. All right. Linux on the cell is a patches that 2.618 power PC kernel, power PC64, and support SPU threads as an API. So everything has been extended to the Linux. And it is part of the mainstream as well. If you go to Linux kernel.org and you download your Linux in there, you would see a lot of patches that came in and view a member of the Linux open source community. As one of the developers, you'll see a lot of patches from the cell that went into the mainline. Now this one available, all the fixes are available from the Barcelona Supercomputing Center. SP management libraries. I mentioned this before so we can manage the SPU threads under the Linux environment. Some workload we've shown here, physical simulations, physical simulation here, subdivision surface on the mesh, and then, you know, refining from that mesh to make it to show a really graphic rendering, a very nice image of the head here. The terrain rendering engine is another example that we showed here that superimpose takes a satellite image which has elevations later superimpose on the holes on top of a flat terrain image and render that image on the 3D versions on one of the displays, a really nice display here. Performance tools as static analysis, SPU timing, dynamic analysis, running on the system simulator or profile FDPR Pro. I mentioned that before. The cell-B IDE, Eclipse-based, which is built on top of the Eclipse SDK here and then the CNC++, development toolkit CDT, and we put in the plug-in for the cell and create an environment for you to write your programs. Really, really nice. Software design considerations. We have a two-level of parallelism here in cell. We have a regular vector engine, right? We have a PPE vector engine. Each of them can run a number of instructions with different data elements concurrently. And then on top of that one, we have the concept of tasking, the threading. You have the task on the Linux. It can be partitioned to different threads as well. So we have at the high level and the low level. We have a different level of concurrency or parallelism running all the time. Computational-wise, we have the SIMD engines. We have a parallel sequence distributed over a SPE and one PPE. And then we have a 256-kB local store for SPU usage. The SPE, remember, we have about the SPU and we have the local store. Local store, we only have 256-kB only. So we have to deal with that one. We have to think about, hey, this memory is so small. How can I fit my program? That's one of the issues. Communicational, we have the DMAid and bus bandwidth. We have some mechanisms so we can transfer data. As fast as possible. How do we leverage that transfer speed? And how do we support the data, how we supply the data to all these tasks running on our SPE? Typical software development flow, we go through the algorithm complexity study. Traditional one, do the same thing. We go to data layout, locality and do some data for analysis. So the dependency studies on your data and some dependency on the control flow of your program. The same thing, right? So basically, we do the same thing up to this point. However, then we said now we have a PPE or we have an SPE. We let's take a look at the PPE program. We develop some PPE control, right? And then we say that, okay, let's the code, the first code will be the Scala code. Develop that code and the PPE is the Scala code. And then we have a Scala code now. We say that let's partition that Scala code down to the SPE. We partition the SPE code and then we take care of communications. We take care of synchronization, latency handling. How do we hide the time, the delay, and so on within our programs. And then we transform the Scala code to the SIMD code, to the vector code. So involving traditionally, we look at the algorithms complexity. We study the same thing. And we take that code, we develop and the PPE. And then we print out the application, the data so that we can send to each of the SPE, providing some sort of mechanisms that control that synchronization. And then we transform that code into the SIMD, vectorize that code, rebalance, try running the first time, second time, using some performance tune analysis here. Analyze the data, the behavior, and then finalize your code. Tuning, performance tuning is never end task, right? So we keep on tuning and then finalizing, checking on the vectorizing code and so on. So this is the typical self-supply development flow that we normally recommend you to go through. Recommending is one thing, but you don't have to go through this, of course, right? Performance-wise, we have a listing here on the floating point single precision, floating point double precision, integers and integers, 16-bit and 32-bit, right? And the red one over here, floating point single precision, extremely fast, extremely good on the cell. This chart here compared the performance of the PowerPC 970 multi-processing, there's two cores here running at 2.5 gigahertz, compared against the cell broadband engine running at 3.2 gigahertz. We're cheating a little bit over here between 2.5 and 2.2, but it's not a whole lot. But we see tremendous jumps in the floating point single precision performance from red right here and the blue right here. Integers, multiplications, 16-bit or 32-bit, very good. The performance of the double precision here remain almost the same, slightly better, but not extremely high or not as... The improvement is not as high as in the other cases. The reason why, because when we designed the processor that was designed to support the game industry, right? And then the focus was... then was to focus on performance of the single precision. To improve the performance of the double precision, we're working in the labs now and in the chart I showed you, the roadmap of the hardware, we released a version of the enhanced double precision performance in the next year, within 2007-2008. So we do recognize some performance problems. We fill some of the demands from the market, depend on the market as well. Some market does not need to have a very high double precision performance, but some is really required and we meet those requirements as well. This chart here shows you the performance difference between the 3.2 GHz general-purpose processor and the 3.2 GHz cell-probe engine and different application areas, high-performance computing, graphic security, video processing, and these are the types of algorithms that we're going through. This is the performance improvement, the performance of the 2.2 GHz GPP. For example, in this case, we've seen it here, running on the cell, we were able to perform this one about eight times, permanent improvement by AX. Depending on how many SPEs we run here, in this case, we run eight SPEs, in this case, one SPE, we put cells here, 30 frames, one frame in this environment, and then the G5, which is the power PC here, let's say the 970, and running against the cell here, about performance improvement, about 12X on the cell. We did see some really performance improvements and some aspects very fast, with very significant improvement as well. Key performance characteristics, what set us apart from the traditional architectures. If you look at the single processor, single processor, we're about the same. The key point is that we have we offer eight SPEs. So whenever you're running something and you've distributed your workload on the different, on the eight SPEs, we can go, we can see an immediate improvement of AX right away. And some of them tweaking, some tuning, some rewriting or retuning of your application, we can see 20X, 50X. And some indication, we can set it up to 100X. The cell plate, this is the cell plate we have now. We have the cell processors, and we have the two plate here, and we have a one-year-bind of XDR memory. And then this is the way that we put the cell plate on the cell plate chassis. We have 14 slots, and each of the cell plate take two slots, and we have seven cell plates in this chassis here. In this configuration, this is the same configuration, the QS20. And then this is how we connect the system together. Either go through to form an XMP system or to form a clustering system. Okay, this is the router, computer rock. This is the one that we plan to connect all of the basic AMD systems connected to the cell B as an accelerator. Application affinities. This is the kind of application we look at. These are features on the left panel here. You have different features of the cell, and this is the kind of function that we believe that could be accelerated, could be improved, could be running faster on the cell. And here we look at different group of applications. Okay? And here is a different target for our industry. We look at AMD, aerospace and defense. We look at petroleum industry, seismic data processing, public and finance, FSS, industrial, on the semi-conductor LCD here, medical imagings, key application areas for the cell broadband engine here. Communications, consumer, digital content creation, media platform, video surveillance. It's a very, very key application. And extremely, when you apply, when you import those applications to the cell, you would see a tremendous jump in performance. The future of the cell B is we're moving from the punch cards 20 years, 30 years ago and up to the client survey here. And then we get into the immersive interaction of the client gaming. Okay? And then these are kind of applications from the window click and wait, we move into immersive, we move to real-time and distributed when we, a lot of data that have to be accessed, that we need to access everywhere, right? On your palm, on your cell phone, for example. And the wireless always on and text messaging, blocks. And now we look at some of the digital world that we're dealing with. From the text-based search engine, you have a Google, you have Entomy, now you have a graphic-based, image-based searching.  Capture that picture and capture the text-based and then retrieval the data. You know, what does it mean to us, right? From this piece of data, from, you know, look at the bottom of your TV screen, whatever. You're running through with some pictures. Capture that and then tell us, you know, and then save that one so it can be retrieval later on.  We do not need the mouse. I still need the mouse over here, right? You saw me from the beginning until now. I, my, my finger is still pointing to the mouse, pointing here, I move the mouse. Why can't I go here and move my finger, my pointing, right? And some camera capture my gesture, right? This one, instead of me, my finger under here. That's my natural gesture, right? Instead of my unnatural gesture over here. So this kind of application we move on and we can see that certain application areas is candidate for the cell here. Dynamic increase of data volumes. We're facing a large set of data volumes, every one of us. From here or in the US or anywhere that I go, right? I use, I flash my credit card. The data's there, it's ready for me. You know, I flash, I swipe it through and then I sign. That's all. Behind that one, they store my data, my record, my date of birth, my bank records, where I've been through, how much I have left in my card there. And sometimes I say that, well, I'm sorry, I cannot, you know, process your card here. Oops, you know, those things happen but they capture my data everywhere, right? Every year and every single moment. You can see that one over here, we created 800 megabytes of data. Now it's just every year we increase that one. 300 megabytes of data. That's not included, that's a text base. Not included in my pictures. A picture of my family posting somewhere on the web and they can download this one as well too. How do you process that one? X-ray of human body. Large set of data, 20 megabytes is low, right? Digital video, 10 megabytes per minute. This video camera here captures a lot of data, right? Put it somewhere. Retrieve that data and process that data. Just imaging this one camera. You have a thousand cameras watching you at the airport, right? Or a city, you know, anywhere in the city except Mumbai. Maybe it's no camera, right? You can try left and right, nobody cares, right? But anywhere, I'm not aware of Brazil. Oh, the system all over. The cameras on the highway as well. If you pass, if you exceed the speed limit at night, right? It's flash, you see the flash? The camera took your picture, take a picture of your car, of your license plate at 9 p.m. In the dark. You see? So when the set of data we go into somewhere, somehow, right? We have the capture that one. Another way that we look at that is of now when you buy the PC, right? The AMD and so on, and you go now and buy a nice graphic card from NVIDIA that some others, ATI and so on, so you can process that data, right? That graphics, nice graphics. You have a CPU in there, you have a memory and so on. On the cell base, you know, we said we'd go ahead, all of those things can be processed within the cell, inside of the cell, right? We have accelerators. We do the processing. We process the image and render the image, processing the data of the image and render the image for you. Instead of, you know, having a separate GPU, graphic processing units, processing the unit for the image for you, as we have now. Here's the look at the traditional graphic-based processor, right? We have the CPU here, we have memory, we have a knowledge connecting to the GPU, graphics processing units over here. The cell bridge connected to the I.O., right? And accelerators with some, you know, companies working on some accelerators to do, to help the CPU here perform some specific operation. On the cell side, we have a 164-bit PowerPC right here, and we have the memory controller. The type of memory is very tight, right? We use a very high-speed XDR memory, okay? And we have a set of processor. We've got the SBE. Eight of them can perform those operations concurrently, and we have a multi-core system right there without adding anything, like accelerators and so on. All of your accelerators, all these functions being performed by each of those SBE. And then you have a flex I.O. to connect to your I.O., and so on. So some things for you to look at in the future, like the specialization in computer architectures, beyond OS application, what specialization makes sense in the general-purpose chip design, okay? And also the programming paradigms, programming changing. We are not programming a single-core system, a dual-core system, an SMP system, a NUMA system even, right? We are moving to a different programming environment here. A lot of you, I think that, you know, working on the multi-core and programming the multi-core from the Intel base and so on and the AMD base, and that's a little bit different than the multi-core in this area here, okay? Here we have a set of homogeneous eight of them and one different, you know, so we can partition our tasks. On the other hand, you must have, or you would have, you know, one set of cores, two or four on a single socket or two socket tied together, okay? And each of them still replicates of a single core, fully implementation of level one, level two cache and so on, the partition. Thus, environment is different in this environment. Programming in this environment is different, a little bit different than what I just described. And the new types of application as well, all right, so that my summarize and then let me, you want to take a break now?


Another good tool for assessing a tree's soundness is to bore the tree. And what you want to do is you want to bore it at 90 degrees to the direction that you're going to fall it. You can see where the color changed and we suddenly got dust. We know that we only have about this much rind on this tree and the rest is hollow.


And somebody says, ooh, he's got the Canadian spirit. Well, the amazing thing is, and this is, I think, I don't think you Americans like to hear this, but the fact is that the people who have the most American spirit are immigrants. In this case, he grew up in South Africa, where I have family roots too. He grew up in South Africa, moved to Canada, and then to the United States. And as an immigrant, these are the kind of people you guys want to build walls, want to keep out, he changed the world. But it's often immigrants who have that American spirit, that spirit of we can do anything, that spirit of nobody's gonna stand in my way, that Howard Walk spirit, if you will, of I am going to make it, even after working at Quarry for a while. Elon Musk has exhibited that throughout his career.