So you're asking them to do a deep, recursive sort relative to the current folder level files and folders reside down to the last file?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Snow Leopard Build 10A421 Seeded to Developers
- Thread starter nozebleed
- Start date
- Sort by reaction score
So you're asking them to do a deep, recursive sort relative to the current folder level files and folders reside down to the last file?
Just asking that it works the same as it always has in Leopard. My hard drive is in the dock, the root level is sorted by kind; the applications folder is sorted by kind; the microsoft office 2008 folder is sorted by kind; the office folder inside that is sorted by kind, and so on. Rather than SL's current way: the root level is sorted by kind; the applications folder is sorted by name; the microsoft office folder is sorted by name; the office folder inside that is sorted by name, and so on. It just makes browsing dock folders that much more difficult, given that one is generally looking to keep going down through folders, which are all in a row when sorted by kind, à la Leopard.
I don't know if anyone else is having this issue, and I'm not going to read through 400+ posts to find out, but I've been having major issues with my Airport connection since updating.
My connection is dropping a lot, and when I try to reconnect, the connection times out, and when it finally connects, I can't connect to the internet. This only happens periodically though.
Don
My connection is dropping a lot, and when I try to reconnect, the connection times out, and when it finally connects, I can't connect to the internet. This only happens periodically though.
Don
What brand of router do you use? what technology does it us? a? b? g? n? have you got the latest firmware installed on it (the router)?
Geekbench 64 on a 64-bit kernel: 4111
Geekbench 64 on a 32-bit kernel: 4063
(on a last-gen MacBook Pro 15')
The difference is 1.2% in performance. Stop whining...
Geekbench isn't even that accurate and there's no point of comparing it because unless I am wrong, there's no 32bit vs 64bit benchmarks in Geekbench, it's just 32bit and 64bit versions of the software, not the 32bit vs 64 calculations. Which means there won't be any difference at all. A real benchmark that uses 32bit version of library and 64bit of library doing intensive math calculations will show a difference bigger than 1.5% or even 10%.
As for macintoshtoffy, just be patient. There's still a month left. If SL goes gold without those intel drivers, than you should complain about it. But Snow leopard is fast in 32bit mode, I have been running it in 32bit for months even though that I could run it in 64bit. Apple could still release the intel drivers in a minor update after SL's release.
The point is that even with a 64-bit optimized bench, if your kernel runs in 32-bit mode, you will *still* be able to run your bench in 64-bit mode with 64-bit libraries. The mode the kernel itself is running in doesn't matter and won't have any performance impact.
It does because in pure 64bit kernel, you gain access to additional GPR (general purposes registers), twice the register size of 32bit CPU or legency mode 64bit CPU. Those registers can be used to process more work per instruction clock and there will be less overhead for a 64bit kernel to use 64bit applications since 32bit kernel has some overhead processing 64bit userspace applications.
That does not mean that all applications will gain performance, in fact some will lose a bit of performance due to the registers now being 64bit wide instead of 32bit.
I thought those registers could be used by 64-bit applications running on a 32-bit kernel. When you compile your app for x86_64, you don't know whether it will run on a 32 or 64 bit kernel, yet the register allocation is done at compile time...
I might be wrong !
I also think that the benchs I've given show that the overhead of running 64-bits apps on a 32-bit kernel is minimal.
I used to have this issue, try changing the wireless channel to something different and see if that helps.
How can I actually check if my system is in Long mode ?
Because that does not seem incompatible to me with the kernel being 32-bit. And http://makfu.wordpress.com/2008/03/07/prepare-to-be-rocked/ reads:
So if you have a way of knowing what registers are actually available to an application, that would be great, because Apple has been touting the increased number of registers since at least Leopard, when the 64-bit Darwin didn't even exist.
If you read carefully that quote you posted, you'll see there there are also overhead for processing 64bit calls with 32bit kernel and processing 32bit calls with 64bit kernel. there'll be less overhead for 64bit processes with 64bit kernel.
Think of it like this, the kernel is the middle man between hardware and the userspace; the area where all of our applications run, all the interactions that occurs for the user. If you have 64bit CPUs, 32bit kernel and 32/64bit apps, the 32bit kernel now has to somehow convert the 64bit calls from 64bit apps since it can't read more than 32bit values. Then send it to the CPU, the CPU processes it, sends back 64bit values, the kernel again has to process those values and convert as 64bit return values to 64bit application. There's a bit of overhead doing all of that.
Now imagine 64bit CPUs, a 64bit kernel and 64bit applications. There's no overhead: it goes to kernel, kernel send it to CPU and vise versa. However, it does have to process 32bit calls, converts it to 64bit, send it to CPU and so on. So 32bit applications will have the same overhead that the 64bit calls had on a 32bit kernel.
That's why I believe it's just better for the future for everything to just go toward 64bit, not matter how simple the application is. That will happen just as we transitioned from 16bit to 32bit and it will happen when we reach the age of 128bit.
^^ Yep. Although I can't see the need for true native "ultra-long" 128bit integer code, at least not for the next 7-8 decades. Doesn't 64bit addressing theoretically allow for petabytes of addressable RAM? Imagine a workstation with 1024 TB of RAM!?
Although I could see how a 128bit integer CPU could be used to process 2 separate 64bit ops simultaneously.
Although I could see how a 128bit integer CPU could be used to process 2 separate 64bit ops simultaneously.
Hey, somebody once said that "640K ought to be enough for anybody".
I agree, we probably won't reach the 128bit age for a while but it will happen sometime within a century if we're still alive.
I agree for the most part. It seems as if we're also taking our sweet time even making use of 4GB of RAM right now... perhaps because of the 64-bit transition, but for the power-using (and gaming, in the case of Windows) I do, I've still not even gotten close to maxing out to 4GB. I've gotten over 3GB, but never to 4. What I think we should see in the next OS generation or so is the OSes caching even more in the memory. We have the overhead that seems to be continually getting bigger. Might as well preload more apps/stuff, etc. etc. to get away from waiting on the hard disk drive.
wait, i paid the 9.95 price. what is this full install? am i not getting the full snow leapord? thx
What I want is an application that actually USES Grandcentral & Open CL.
64bit is just memory addressing and really will not improve the performance as much as the above technologies will..... but.. Nothing uses them yet.
64bit is just memory addressing and really will not improve the performance as much as the above technologies will..... but.. Nothing uses them yet.
Easy, any application that uses NSOperations automatically inherits Grand Central goodness.
As for OpenCL, I am unsure as to whether the CODECs by Apple are utilising OpenCL, however, I have a feeling that this is a foundation release with future releases of Mac OS X taking advantage of OpenCL.
I'm looking at a new MacBook but I am wary of Nvidia given the high failure rate of their products.
Yes, just memory addressing - you're ignoring the many pages which refute exactly what you said; heck you ignore this page you posted your opinion on where considerably more knowledgeable people have clearly outlined why your assertion is false.
Are you sure? I remember reading the GCD brief from Apple stating that the code needs to be converted to GCD dispatchable syntex.
Read the PDF located at this SL's GCD page.
As for apps taking advantage of GCD and OpenCL, that's months and in some cases, years away. Snow Leopard is the seed that will start off the next generation of GCD/OpenCL enabled applications.
From what I understand - NSOperations in Snow Leopard is built upon Grand Central; the issue was addressed a while ago when the question regarding Cocoa applications and Grand Central was raised by me.