Print 73 comment(s) - last by Calin.. on Jul 27 at 4:05 AM

Native quad-core en route

Comments     Threshold

This article is over a month old, voting and posting comments is disabled

RE: Why is everybody killing AMD????
By Tyler 86 on 7/23/2006 5:57:16 AM , Rating: 2
When I say 'JIT-less', I mean Singularity has a compiled assembly base, but everything ontop of it - 90% to 95% of the entire operating system, even at boot - is compiled either at or before runtime - core elements being pre-compiled, but compiled to assembly nonetheless, every time...

It's effectively taking the JIT out of a JIT compiler...

... but I guess that's nothing really new, so nevermind.

Sure. It's all JIT.

RE: Why is everybody killing AMD????
By Tyler 86 on 7/23/2006 6:03:28 AM , Rating: 2
Advances in languages, compilers, and tools open the possibility of significantly improving software. For example, Singularity uses type-safe languages and an abstract instruction set to enable what we call Software Isolated Processes (SIPs). SIPs provide the strong isolation guarantees of OS processes (isolated object space, separate GCs, separate runtimes) without the overhead of hardware-enforced protection domains. In the current Singularity prototype SIPs are extremely cheap; they run in ring 0 in the kernel’s address space.

You're able to effectively run everything you 'trust' at kernel level ring 0 code. That is as close to the processor as you can get. It boggles the average software developer's mind.

RE: Why is everybody killing AMD????
By Tyler 86 on 7/23/2006 6:13:23 AM , Rating: 2
Singularity achieves good performance by reinventing the environment in which code executes. In existing systems, safe code is an exotic newcomer who lives in a huge, luxurious home in an elegant, gated community with its own collection of services. Singularity, in contrast, has architected a single world in which everyone can be safe, with performance comparable to the unsafe world of existing systems.

A key starting point is Singularity processes, which start empty and add features only as required. Modern language runtimes come with huge libraries and expressive, dynamic language features such as reflection. This richness comes at a price. Features such as code access security or reflection incur massive overhead, even when never used.

A Singularity application specifies which libraries it needs, and the Bartok compiler brings together the code and eliminates unneeded functionality through a process called "tree shaking," which deletes unused classes, methods, and even fields. As a result, a simple C# "Hello World" process in Singularity requires less memory than the equivalent C/C++ program running on most UNIX or Windows® systems. Moreover, Bartok translates from Microsoft® intermediate language (MSIL) into highly optimized x86 code. It performs interprocedural optimization to eliminate redundant run-time safety tests, reducing the cost of language safety.

Because the code is an abstract recompilable element, and the intention and boundries are clearly visible to the compiler, they can run natively at ring 0 at full throttle, after their initial compilation.

If you ever played with .NET, you know just how fancy, abstract, intricate, and easy C# is -- and you probably also know how painfully slow it can be due to it's 'management'. Even with 'unsafe' tags, things are hairy compared to C++ and native assemblies.
Singularity is effectively nativized C#.

RE: Why is everybody killing AMD????
By Tyler 86 on 7/23/2006 6:17:33 AM , Rating: 2
This is only a glimpse of the future.
Fortunately, for desktops; unmanaged untrusted abstractable JIT code can exist - just not in Singularity, which is intended as a server operating system.

"Yesterday's" JIT applications immediately recieve the benefits of "today's" processors. Cores, instructions, architectures. It's all in the upgradable compiler, and the upgradable libraries referenced.

By Tyler 86 on 7/23/2006 6:21:42 AM , Rating: 2
Aggressive interprocedural optimization is possible because Singularity processes are closed—they do not permit code loading after the process starts executing. This is a dramatic change, since dynamic code loading is a popular, but problematic, mechanism for loading plug-ins. Giving plug-ins access to a program's internals presents serious security and reliability problems [snip]... Dynamic loading frustrates program analysis in compilers or defect-detection tools, which can't see all code that might execute. To be safe, the analysis must be conservative, which precludes many optimizations and dulls the accuracy of defect detection.

"Well, there may be a reason why they call them 'Mac' trucks! Windows machines will not be trucks." -- Microsoft CEO Steve Ballmer

Copyright 2016 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki