[eddiecatflap]

i agree with that , spotlight is ok , but not much better than panther's search

and the widgets are just a silly gimmick

maybe os-x peaked with panther ? who knows ??

[Don Pickett]

Originally Posted by occupant

No, I think quite a few of the problems exist with the 150 bucks I spent to find out it was no better than what I had. Panther added to the system (mainly in terms of performance/UI consistancy). Tiger doesn't seem to. The new 'features' don't help my workflow, there are old features I need and now need to find alternatives for. Basically I feel like I paid 150 bucks for vpn software that works as advertized. I wouldn't say it 'sucks' but I think Tiger is a short on value.

The changes under the hood are more than worth it. Fine-grain thread locking was long time coming.

[Randman]

Then why didn't you look into what Tiger had to offer you before buying? You didn't have to buy it, you know. You could have stayed on Jaguar or Panther or upgraded after a few update releases.

[eddiecatflap]

probably beacuse i'm stupid and buy anything with an apple logo on it



hey , at least i'm honest !

[pliny]

upgrade install: 0 problems
clean install: 0 problems

Tiger working great here, on old machine too.

[occupant]

Originally Posted by Don Pickett

The changes under the hood are more than worth it. Fine-grain thread locking was long time coming.

How does this improve my end user experience? Changes under the hood are just that - under the hood. I don't see them. Enless they rev things up I don't notice them. I am not revving higher with Tiger.

So are you saying I should be happy to pay for invisible changes that don't effect my day to day experience? I don't get this.

Originally Posted by Randman

Then why didn't you look into what Tiger had to offer you before buying? You didn't have to buy it, you know. You could have stayed on Jaguar or Panther or upgraded after a few update releases.

As for why I didn't look into the product before purchasing it - I did. As I said, I have had a long-standing issue with VPN connections. This is now fixed. Great. Thanks. They also claimed it worked in 10.3.

Funnily enough I missed the part of the sales literature that listed what Apple removed/changed. Silly me for thinking that if it wasn't broken, they wouldn't cull it.

[Don Pickett]

Originally Posted by occupant

How does this improve my end user experience? Changes under the hood are just that - under the hood. I don't see them. Enless they rev things up I don't notice them. I am not revving higher with Tiger.

So are you saying I should be happy to pay for invisible changes that don't effect my day to day experience? I don't get this.

I am not quite sure how to answer your question, because it seems to be bordering on trolling. The under the hood changes are the most important ones, because they are improvements in the guts of the operating system. It's as if you're complaining that OS X got 50 extra horsepower but didn't get a spoiler on the back end.

From the Ars Technica article on Tiger:

In earlier versions of Mac OS X, the kernel was essentially single-threaded. That is, only one thread could be in the kernel at any given time. Other threads could continue to run, so long as they did not run code that needed to execute inside the kernel.

For example, a fractal-generating application does not need to be in the kernel in order to do the calculations necessary to draw the next iteration of the fractal image. On the other hand, an application that wants to do any network, file or device i/o has to go through the kernel to do so.

The Mac OS X kernel uses locking to enforce these constraints. In Panther and earlier, any code that needs to call into the kernel to get its work done first has to grab the "kernel lock." If another thread already has the lock, the thread that wants it simply has to wait until it becomes available again. Now imagine 50 different threads all trying to get the kernel lock at the same time and you have what is known as "lock contention." The lock itself is also known as a "funnel" because it conceptually funnels all of the contending threads into a single, serialized stream of activity.

I described the pre-Tiger kernel as "essentially" single-threaded because it actually implements a "split funnel" system. As described earlier, a thread that wants to execute in the kernel needs to grab the kernel funnel. But if it needs to do network i/o only, it can give up the kernel funnel and pick up the network funnel. In other words, there's effectively one funnel for networking and one funnel for "everything else" in the kernel. As it turns out, that "everything else" is usually file i/o, so the kernel funnel is sometimes also called the file system funnel.

Even with the split funnel, this system is what is known as coarse-grained locking. The bigger the chunk of functionality protected by a lock, the coarser the lock is considered. And the coarser the locking, the more chance there is for contention. One "kernel funnel" and one "networking funnel" make for a very coarse setup indeed.

Matters get worse when you consider a multi-CPU system. More simultaneous threads vying for the same number of kernel locks means more contention. There are no Macs with more than two CPUs right now. But let's face it, a dual-core, dual-chip Mac is inevitable at this point. ("Confirmed!!!") Such a beast won't take too kindly to a split funnel kernel. What's an OS to do?

Finer-grained locking is the obvious solution. Instead of restricting access to huge chunks of the kernel, locks can be placed in front of smaller pieces of functionality. For example, instead of allowing only one thread at a time to do "any network i/o" in the kernel, smaller locks can be placed on the various parts of the networking stack: memory buffers, sockets, the protocol layer, etc.

Since there can be as many threads running in the kernel as there are individual locked pieces, more locks means more threads and a lower chance that a thread will want exactly the same lock as another thread. The end result is less contention, and the ability to scale to a higher number of CPUs (or "cores" with multi-core CPUs, or "threads" with symmetric multithreading).

On the other side of the coin, there is a measurable amount of overhead required to do the bookkeeping and synchronization for each lock. More locks means more overhead. At a certain point, more time is spent doing lock management and synchronization within the kernel than was saved by introducing finer-grained locking in the first place. So while extremely coarse locking like Panther's split funnel is obviously suboptimal, it's also unwise to go too far in the other direction, with tons of tiny locks on every single bit of kernel functionality.

The easiest way to determine the optimal scope for a kernel lock is to start coarse-grained (which is the easiest to implement) and then get progressively finer-grained until performance stops increasing under a typical load for that subsystem. This is the technique Apple used to develop the Tiger kernel. Tiger does away with the split funnel and replaces it with locks on the logical pieces of each kernel subsystem.

For example, a thread making a file i/o system call might start by grabbing the generic system call handler lock, then drop it and grab the lock on the file descriptor handler, then drop it and grab the lock on the kernel's file data structure access code, then drop it and grab the lock on the file system access code, and so on.

As soon as a thread drops a lock, another thread can pick it up, leading to a series of threads traversing well-defined pathways through each kernel subsystem, picking up and dropping locks as they go. In practice, it behaves a lot like "pipelining" does in a CPU, but has its own, different trade-offs for "pipeline length" (number of locks) and overall throughput.

I have noticed the Finder is much more responsive, and I attribute that to the thread locking: I rarely see a spinning beachball anymore. I also like other things – ipfw now writes to ipfw.log, fr'instance. From your comments, it looks like something's wrong with your machine or your install. No problems with Tiger here.

[occupant]

Originally Posted by Don Pickett

I am not quite sure how to answer your question, because it seems to be bordering on trolling. The under the hood changes are the most important ones, because they are improvements in the guts of the operating system. It's as if you're complaining that OS X got 50 extra horsepower but didn't get a spoiler on the back end.

I have noticed the Finder is much more responsive, and I attribute that to the thread locking: I rarely see a spinning beachball anymore. I also like other things – ipfw now writes to ipfw.log, fr'instance. From your comments, it looks like something's wrong with your machine or your install. No problems with Tiger here.

Trolling? Because I don't agree with you? I have stated I have issues, and outlined those issues. The VPN, Appletalk and Find issues are all well documented in Apple Discussions and not perceptual.

As I said, my performance has decreased (marginally, but it has). Perhaps there is an issue with my install, but the number of like complaints I have seen make me sceptical.

As for the Ars Technica article, I am aware of all that, but it has not translated into "50 extra horsepower" whatever that means. So, if my install is fine, which I suspect it is (although I am still haunting discussions to prove myself wrong), then those 'under the hood improvements' are of dubious value to me and potentially others.

[besson3c]

Tiger wasn't so bad

[Spheric Harlot]

You dredged up a SEVEN-YEAR-OLD THREAD to tell us that?

[OreoCookie]

No, Spheric, I think besson is trying to tell us that auto locking of threads no longer works