[surjones]

So it's been a month or and we are waiting for SL to come out. I was on apple site looking at their page about SL but did not see anything of Release date, price, important features etc. I dont get on the forums too often, so I am a bitout of the loop

[Brad]

I don't think there have been any announcements or other news about Snow Leopard lately.

Moving to Speculation and Rumors.

[jondaapplegeek]

Originally Posted by surjones did not see anything of Release date

It was announced in June 2008, and is expected 'about a year' later, so one would guess June / July 2009.

Originally Posted by surjones price

Not know. Some think it will be 'full price' (£85 / USD equivalent), some think it will be slightly cheaper because...

Originally Posted by surjones important features etc

... there aren't any major features as such. New safari, new quicktime and MS Exchange 07 support and some coding things 'behind the scenes'.

[Kickaha]

Originally Posted by jondaapplegeek It was announced in June 2008, and is expected 'about a year' later, so one would guess June / July 2009. Not know. Some think it will be 'full price' (£85 / USD equivalent), some think it will be slightly cheaper because... ... there aren't any major features as such. New safari, new quicktime and MS Exchange 07 support and some coding things 'behind the scenes'.

There will be major features... just not ones that Ma & Pa Jones are going to care so much about directly. What they *WILL* care about is how their apps run significantly faster on the same hardware. That will be the marketable feature from the core technologies.

[Fahrenheit]

Yep, for example, Mail.app will be 196MB smaller, or 68% of its current size. Hopefully, with changes like this across the board we will see a more secure, more speedy package.

edit: These are the sizes lost of apps in Snow Leopard.



Courtesy: Hawkwings.net

[jondaapplegeek]

Just out of interest, to someone who doesn't understand coding other then html and such, how do Apple reduce the size of an app to that extent? What are they actually changing?

[Banana]

I'm guessing by pruning dead codes (e.g. blocks that were used once but since hasn't been used), using more efficient methods, offloading common routines to a library or at least making blocks more reuseful for various cases, removing spot exceptions.

There may be more that I don't know about, though. That said, I have to say I'm impressed that they can shrink apps that dramatic, as the above I gave doesn't usually do that... can it?

Edit: (What a silly fucker I am. I also forgot that Snow Leopard is supposedly Intel-only, so they may be also dropping PPC code as well... But doesn't that goes against the yellow box principle?)

[Kickaha]

llvm

*grin*

[Banana]

What about your wife?

I kid, I kid.

I'm still not sure if I grasp it. LLVM is supposed to be better than Universal binary because we just have a source code and compile it just in time for target system? So they just need to pass around the source code or at least a precompiled edition and let each system compile it when it's being installed?

[Kickaha]

Installed? Nope. Try runtime.

You can load balance across cores, across CPU/GPU, whatever you have access to, dynamically.

Sound kind of like what they announced at WWDC?

Oh, and it doesn't need the source code - you 'compile' down to llvm's internal language, then save that, and emit the proper binary at runtime using a JIT backend.

Think of it this way... a traditional compiler chain looks like this, roughly.

Source -> parse -> AST -> optimize -> convert-for-execution -> .o files/libraries -> linker -> executable

LLVM breaks this up slightly differently:

Source -> parse -> llvm IR files -> optimize -> link -> convert-for-execution -> executable

This means that your conversion for execution can be an interpreter, a JIT, or a traditional static compiler. You can write optimizers for any backend, any language, and they'll work. In fact, you can add all sorts of neat tools into the slot marked 'optimize' in the LLVM tool chain, as long as you can consume and produce an LLVM IR file.

You can think of the LLVM IR as language-independent Java bytecodes designed by intelligent people.

So you compile your code to the LLVM IR files, and save those. Then at runtime, you load those in, inspect your current hardware capabilities, and JIT as needed. Truly universal binaries... whatever hardware you have, you use. Imagine if all the apps worked this way... or if the System libraries did. Or the OS.

Now, this is sheer speculation on my part, but all the pieces are there, and Apple has been using llvm for CoreImage and CoreAnimation for a couple of years now. That's how they get the GPU-agnostic compilation for developer's code.

[Mugge]

So if you don't even understand Java code, then you must be qualified to live in a trailer park?



I'm beginning to get good at drinking really cheap whiskey so I guess there are no conflicts there.

[Banana]

This sounds very neat and all that. Just one thing I'm not quite if I understand completely.

Wouldn't it then make it expensive to make a truly optimized application? That is, at runtime, I'd have to test for so many details before knowing that so and so features can be used to improve the performance, and if necessary, enable the interface for the end user to employ those. Therefore to support several systems, the optimization process would consume far more time than if I just had written application's private libraries that access the hardware directly?

I'm 110% sure that what I'm envisioning is seriously flawed and would love to hear how it is flawed.

Edit: Just remembered that the optimization is actually left up to whoever wrote the optimization code for LLVM IR file (?) -> executables portion which would be more likely the manufacturer of the system or OS developers, not the application developers, so I just develop the application and let them handle the optimization, so the only thing I need to do is to test if so and so hardware is there or not and enable/disable features where necessary... right?

[Kickaha]

Originally Posted by Mugge So if you don't even understand Java code, then you must be qualified to live in a trailer park?

No, it's just that the bytecode format defined for Java was about the most simplistic, brain-dead variant they could have come up with. Instead of retaining information that would have made later optimizations for JIT or compilation to a binary possible, they threw away most of the interesting stuff. Granted, their vision of a single-stack-model JVM everywhere meant that it made sense for their model... it just wasn't a model that worked for most people, and limited Java in the long run. Essentially, they weren't thinking far enough ahead.

Back in '96 there was a project out of (IIRC) Florida State called Orange that was essentially Java bytecodes with enough AST info to allow for some really neat optimizations. It's too bad it never took off. LLVM is sort of the successor to that, in feel.

[Kickaha]

Originally Posted by Banana Edit: Just remembered that the optimization is actually left up to whoever wrote the optimization code for LLVM IR file (?) -> executables portion which would be more likely the manufacturer of the system or OS developers, not the application developers, so I just develop the application and let them handle the optimization, so the only thing I need to do is to test if so and so hardware is there or not and enable/disable features where necessary... right?

You don't even do that. The OS/launcher does. "Ah, launching this app, and we have this bit of code that is doing vector processing... oh hey, we have a powerful GPU, I'll send it there. And this piece is pretty straightforward, but needs lots of registers... ah ok, off the CPU you go, pick your core, any core... oh, and now this piece uses two NSTasks that coordinate, we'll send you guys to two cores on the CPU so you can yack with each other more effectively, and..."

The developer just writes the code. Right now, you don't have to think about the optimization possibilities for the hardware, in most cases - you trust the compiler and linker to take care of it for you. Whoever wrote those, it's their responsibility to know how to take the best advantage of it, right? (Sometimes you need to fine-tune based on the compiler output for specific hardware, but those are rare in most development cases.)

Like I said though, this is all rampant speculation on my part.

[Banana]

So, with LLVM, we actually develop?

[Mugge]

We have this application for communicating with the tax authorities at work that is written in Java. For what it does it's the slowest program I've ever experienced. And the worst part of it is that it could just as well have been a simple HTML form. Now that I think of it I can't recall any application written in Java at all that's not slow and ugly. The ambition about taking over the internet and sit on top of Windows' face hasn't quite come true.

I sure hope Snow Leopard isn't going to be anything like Java.

[Banana]

Mugge,

Don't know much about java, but I understand that it was basically intended to be basically virtualized and self-contained, so you didn't have any dependencies on the hardware or OS's libraries (a big reason why it looks ugly; it uses own libraries rather than OS's native libraries, especially for drawing forms), to meet the requirement of "compile once, run anywhere". The problem was that it meant having a virtual machine on each machine, and having a team to optimize the machine for a particular build (and individual pieces of hardware as well).

So, Kickaha, would LLVM avoid that problem or something like that?

[Mugge]

@ Banana

Yeah, that was my understanding of the basic idea too. But now you mention the part about libraries for drawing things I kinda understand why it's do ugly. It would have to be able to run on almost any machine, so the bar would have to be set accordingly low. Thus, when you see it on OS X or even Windows XP it just looks like shit compared to the rest of the desktop.

[rasmits]

I thought Snow Leopard's apps were significantly smaller due to a lack of localisation - something most Apple beta apps lack. Once they've reached final, shipping quality they'll localise it for other languages and back comes the bloat.

[Brad]

Originally Posted by rasmits I thought Snow Leopard's apps were significantly smaller due to a lack of localisation - something most Apple beta apps lack. Once they've reached final, shipping quality they'll localise it for other languages and back comes the bloat.

Yup.

TextEdit, for example, is 1.5 MB on my 10.5 system, far from the 22 MB suggested by the graph above, of which only 264 KB is the actual executable. The RoughlyDrafted sizes for the current Leopard system must include every localization available.

[Kickaha]

Originally Posted by Banana So, Kickaha, would LLVM avoid that problem or something like that?

Yes, or rather, no.

As you point out, Java apps are using Java APIs for, well, everything. Java steps in and tries to replace much of the OS and native windowing environment with it's own Sooper Speshal Stuph. (And then Eclipse does the same thing on top of *that*, and then Rich Client Platforms do the same thing on top of *THAT*, and... oy.) If you're using an environment that requires using the native APIs, you're not going to get OS-agnosticism, like you do with Java. ie, you couldn't take an LLVM compiled Cocoa app and run it on Windows.

But what you will get is *hardware* independence, at a very low level. If you had Mac/Intel, Mac/PPC, Mac/Alpha, Mac/AMD, Mac/ARM, and various permutations with GPU hardware, a developer would only have to compile to one llvm blob, and the launch system would take care of the rest. Instead of a Universal Binary containing n executables, it would contain one llvm blob, and it could be JIT'd, pre-emitted (static compiler) and cached inside a bit like today's UB bundles, etc. A lot of flexibility, but with a simple deployment strategy.

Different thrust than Java. You still will be tied to a particular OS/API, but that OS/API/libraries/app can be more flexible in what device it runs on.

[chucker]

Incidentally, Chris Lattner's job position just got bumped. (via John Siracusa)

[Kickaha]

Sweet.

[Paranoid666au]

...and delivered several key architectural features of the Mac OS X 10.6 Snow Leopard operating system (which are still not public)

Awesome. I do hope that this leads to my App folder getting smaller, it's almost 20GB now, might have to do some more pruning.

It sounds like LLVM might be more to do with making it easy to develop across the different architectures, which allows Apple to be more platform agnostic. Developers develop for OS X and OS X runs on anything (that Apple wants it to run on). Guess that makes OS X the ultimate Java machine.

[Unch]

Interestingly, I was reading about a meeting of Java and LLVM just the other day.

There is a project to get a platform neutral OpenJDK JVM that uses no machine specific code. Guess what they're using to provide JIT...

[Kickaha]

Gee, whodathunkit.

[omem]

Could the reason they're reducing the size of the OS is so they can move to solid state memory on all laptops? SSD is still expensive, so any GB saved is precious. Just guessing.

[Dave]

Originally Posted by omem Could the reason they're reducing the size of the OS is so they can move to solid state memory on all laptops? SSD is still expensive, so any GB saved is precious. Just guessing.

It's an interesting idea, but I'd have to say no. Or, at least that Apple's not moving to exclusively SSDs. My home directory is about 160GB, versus just 26GB for my apps folder. Even ignoring the apps folder, I still have more data than will fit on the biggest SSD that Apple currently offers. The vast majority (112GB) of that is music, and I'm sure that I have more than most. But Apple's big push lately has been for people to use their macs to make home movies, and video takes up ungodly amounts of space. Not everyone will be doing that though, so I will grant you that Apple could be looking at making SSDs an option across the line.

[Moogs]

Originally Posted by omem Could the reason they're reducing the size of the OS is so they can move to solid state memory storage....

Fixed. All memory (RAM) is solid state...

[Chinney]

Is there any confirmation that SL is Intel only?