計(jì)算機(jī)專業(yè)畢業(yè)外文翻譯--托管代碼的優(yōu)點(diǎn)(參考版)
2025-05-16 17:42本頁(yè)面
【正文】 at runtime the final stage of pilation can then be easily acplished so that the code will run on that particular platform. In other words, by piling to IL we obtain platform independence for .NET, in much the same way as piling to Java byte code gives Java platform independence. You should note that the platform independence of .NET is only theoretical at present because, at the time of writing, a plete implementation of .NET is only available for Windows. However, there is a partial implementation available (see for example the Mono project, an effort to create an open source implementation of .NET, at ). Performance improvement Although we previously made parisons with Java, IL is actually a bit more ambitious than Java byte code. IL is always JustInTime piled (known as JIT pilation), whereas Java byte code was often interpreted. One of the disadvantages of Java was that, on execution, the process of translating from Java byte code to native executable resulted in a loss of performance (with the exception of more recent cases, where Java is JIT piled on certain platforms). Instead of piling the entire application in one go (which could lead to a slow startup time), the JIT piler simply piles each portion of code as it is called (justintime). When code has been piled once, the resultant native executable is stored until the application exits, so that it does not need to be repiled the next time that portion of code is run. Microsoft argues that this process is more efficient than piling the entire application code at the start, because of the likelihood that large portions of any application code will not actually be executed in any given run. Using the JIT piler, such code will never be piled. This explains why we can expect that execution of managed IL code will be almost as fast as executing native machine code. What it doesn’t explain is why Microsoft expects that we will get a performance improvement. The reason given for this is that, since the final stage of pilation takes place at runtime, the JIT piler will know exactly what processor type the program will run on. This means that it can optimize the final executable code to take advantage of any features or particular machine code instructions offered by that particular processor. Traditional pilers will optimize the code, but they can only perform optimizations that are independent of the particular processor that the code will run on. This is because traditional pilers pile to native executable before the software is shipped. This means that the piler doesn’t know what type of processor the code will run on beyond basic generalities, such as that it will be an x86patib
畢業(yè)設(shè)計(jì)相關(guān)推薦
鄂ICP備17016276號(hào)-1