If they are intended to use the new 7448 cpu's from Freescale, then that could be why we haven't seen them.
Apple's fortunes have waxed and waned depending on the ability of their suppliers to deliver what they have promised on time and at speed. That's why Apple is leaving them after all.
These chips are delayed. That could be why Jobs canceled his keynote at the Paris fair.
And you know this because?...
Freescale's press release in June said they'd not be in volume production till October. Perhaps Jobs was hoping they'd be ready earlier - I know WE all are.
Wait till October, then bash them.
Aside from that, we've no idea if this update is going to include DDR2, SATA or other features rumoured in the Intrepid2 chipset. Maybe that's late. ie. we don't know. But bashing Freescale for not delivering early is a but harsh.
Freescale's press release in June said they'd not be in volume production till October. Perhaps Jobs was hoping they'd be ready earlier - I know WE all are.
Wait till October, then bash them.
Aside from that, we've no idea if this update is going to include DDR2, SATA or other features rumoured in the Intrepid2 chipset. Maybe that's late. ie. we don't know. But bashing Freescale for not delivering early is a but harsh.
I've been dealing with Powerlogix recently. I've bought several boards from them. They've got boards waiting on the 7448's. A month or so ago they had a meeting with Freescale about the 7448's and the 1.4GHz 7457's. They were told that the 7457's would be delayed slightly (the boards just came out). They were also told that the 7448's might be delayed slightly as well.
I've also read this the past week elsewhere.
Even if the chips were available NOW, it would take time to build them in. The question is; what does volume mean? If the chips were ready, Apple could have recieved 20 thousand already. That wouldn't be considered as volume, but would be enough to prepare an initial shipment. If the chips were then delayed (usually because of an early production glitch), Apple would have to pospone their introduction.
boy this is so so sad if the whole apple expo was f*cked because of freescale, surprise, yet again, dissapointing apple. and jobs having to move the nano intro up to sep 7th to override the motorola itunes phone nonsense. what fucking deadweights. can you tell my sour mood today?
boy this is so so sad if the whole apple expo was f*cked because of freescale, surprise, yet again, dissapointing apple. and jobs having to move the nano intro up to sep 7th to override the motorola itunes phone nonsense. what fucking deadweights. can you tell my sour mood today?
thanks for the understanding peoples, i love y'all
well, i had to terminate my arrangement with a certain school this morning. some will think my actions lame but my mental health and long term sustainability is more important. hint: i'm not a student. well, no contract signed yet so legally its clean. just gotta deal with the professional and emotional fallout, but a huge weight off my shoulders. something was just not jiving.
okay, back on topic for a sec:
so it's still very up in the air about the powerbooks at apple expo huh? i think with nano and .mac updates and apple clearing this quarter with strong financial results (most likely) ... we'll see new powerbooks and powermacs oct/nov. you heard it here first just my 0.02 malaysistan dollars
More than just about any Apple computer product is seems, the powerbook is the one machine that garners the most speculation and talk.. sure everyone wants 20ghz 4 core powermac and blah blah, but not that many people actually buy them for personal use. The powerbook they do. Due to its history/heritage of innovation and the like in the portable range, it feels to me that the powerbook *is* Apples flagship product. Once we get merom a lot of the problems go away but Apple still need to make it special, simply matching dells specs with cpu, gpu etc just isnt enuf.
*hugs 1.5 15" and dreams of her younger sister in 12 months*
I can't see any particular reason why OS X software would be slower on CPU benchmarks than Windows software. If a company is building with the Intel compiler on Windows, they'll probably do so on MacOS as well. Also, GCC is apparently much better on x86 - within 20% of the Intel compiler according to some testing I've seen - and probably just as fast as the widely used MS compiler.
The areas of concern would be:
1) Software that still uses QuickDraw, because apparently that's considerably slower than the new APIs. OTOH, Windows GDI will probably be running in a similar penalty mode under Vista.
2) Games, particularly DirectX games that run through an OpenGL translation layer. Also the OS X Doom3 benchmarks supposedly pointed OpenGL drivers out a weak point. However, nobody buys Macs for the FPS, so no biggie.
3) Server benchmarks, such as I/O or multiprocessing, where OS X hasn't always shown well.
1) QuickDraw has been deprecated for quite a long time now, and I've read somewhere (really don't remember the link, sorry) that Apple didn't intend to keep QuickDraw in Mac OS X after 2007-2008. I guess some dinosaur apps will have to be rewritten a little, and that's not bad!
2) 3D cards drivers for the Intel Macs will certainly share a lot of code with the PC version. Nvidia cards drivers for Intel builds of Linux are already quite good. So let's be optimistic in the GL field! Plus Vista will only provide GL support through an emulation layer, leading to crappy performance.
3) OS X will never lead on I/O performance, as it is a microkernel-based operating system. On multiprocessing, however, Tiger has brought a nice speedup, thanks to finer grain kernel locking etc... That's not bad news!
so it's still very up in the air about the powerbooks at apple expo huh? i think with nano and .mac updates and apple clearing this quarter with strong financial results (most likely) ... we'll see new powerbooks and powermacs oct/nov. you heard it here first just my 0.02 malaysistan dollars
I agree with you. Incremental bumps in oct/nov is all we're likely to see for Powerbooks. Dual-core 970MP is still possible for the same timeframe on Powermacs.
"...QuickDraw has been deprecated for quite a long time now..."
yes, goodbyes to quickdraw.
"...Nvidia cards drivers for Intel builds of Linux are already quite good..."
for some reason earlier i got screen corruption but in the past few weeks after using Suse9.3 online update to get the nvidia driver, no problems at all, plus nvClock overclocking on linux has been decent. quake2 demo sdl opengl linux is flawless on my linux setup. yes its quake2 but running at 1280x1024, 16xAF 16xAA.
"So let's be optimistic in the GL field! Plus Vista will only provide GL support through an emulation layer, leading to crappy performance..."
that's weird, that means microsoft is betting heavily and targeting the gaming market what about 3d apps that use PC windows workstations for maya/3dmax/etc? how are they going to handle the openGL hit on vista? or have alias and discreet figured a way to get around this problem... curious...?
"OS X will never lead on I/O performance, as it is a microkernel-based operating system. On multiprocessing, however, Tiger has brought a nice speedup, thanks to finer grain kernel locking etc... That's not bad news!"
well, it's good news for consumer desktop and enterprise desktop possibilities... but what does this mean for os X server? given that, as the benchmarks suggest, os X server gets creamed by say, linux-on-opterons for mysql...??
well, it's good news for consumer desktop and enterprise desktop possibilities... but what does this mean for os X server? given that, as the benchmarks suggest, os X server gets creamed by say, linux-on-opterons for mysql...??
The comment on the bottom of the changes is from Dominic Giampaolo at Apple and explains why it is slower - extra safe flushing on OSX. Linux doesn't flush the data from a drive's cache so will always be faster.
Secondly, some drives don't honour an F_FULLSYNC and simply tell the OS that they've done it. Apple don't ship drives that lie so in a benchmark test you have to be careful comparing one drive to another.
So if you want speed - go Linux but be sure you've always got power to your server or it may corrupt the database. Worse, if your drive lies, MySQL might think it's done it's flush, power goes and when you're back up MySQL thinks everything is ok but the drives didn't finish writing.
If you want safe data - go OSX.
I suspect there's something MySQL could do to improve performance and match OSX's scheme of safe writing of data, such as writing less often but at the moment it's more reliant on the Linux methodology of writing often and presuming the drives don't lie.
I'd hope someone at Apple would address MySQL performance directly as it's pretty important these days for a server.
but what does this mean for os X server? given that, as the benchmarks suggest, os X server gets creamed by say, linux-on-opterons for mysql...??
As I told you, Mac OS X now lags behind Linux, and will always lag behind Linux, in the field of I/O performance. That's an architectural choice : Mac OS X is based on the Mach microkernel. A microkernel only handles very primitive low-level tasks, such as memory allocation, multitasking, etc... Higher-level services are booted out of the kernel. That's very clean, and it really makes sense, but it's also rather slow.
Linux is a monolithic kernel : the filesystem and a lot of other stuff is included right into the very kernel. Awful architecture, fast execution.
By the way, the "good news" I was talking about was the SMP boost on Tiger. I was not talking about I/O. I/O performance still suck and that's a problem for Mac OS X Server.
quality? data integrity? bah, who cares about that? speed, power, big benchmark numbers. YEAH.
nah, seriously aegis and rescue, thanks for clarification on that. now at least i have a clearer picture on mysql on os x versus linux. and this microkernel thing....
It isn't the microkernal that's the problem. The way the OS passes and releases threads seems to be the problem. Basically it takes too many steps. I've been told that Apple is working on it, but that it might take a while.
It isn't the microkernal that's the problem. The way the OS passes and releases threads seems to be the problem. Basically it takes too many steps. I've been told that Apple is working on it, but that it might take a while.
I never said that the microkernel was the cause of all the speed issues in OS X. However, it really slows down the I/O part. Now i don't know if that's the main bottleneck on MySQL, but that sure is one, since database processing uses mass storage like a bitch.
I never said that the microkernel was the cause of all the speed issues in OS X. However, it really slows down the I/O part. Now i don't know if that's the main bottleneck on MySQL, but that sure is one, since database processing uses mass storage like a bitch.
Mass storage I/O has very little to do with this. It's the transactions carried out in the database as it works through the OS. Thread handling is where the problem is found.
It isn't the microkernal that's the problem. The way the OS passes and releases threads seems to be the problem. Basically it takes too many steps. I've been told that Apple is working on it, but that it might take a while.
In the case of MySQL I thought this was to do with the fsync() differences between linux and OSX. ie. nothing to do with kernel threading
Mass storage I/O has very little to do with this. It's the transactions carried out in the database as it works through the OS. Thread handling is where the problem is found.
Quoted from the book "High Performance MySQL", chapter 6, "Server Performance Tuning" : "This all means that the first bottleneck you're likely to encounter is disk I/O."
However, thread handling also seems to be an issue, and it seems to be a FreeBSD flaw : "Another popular free operating system, FreeBSD, has threading problems that are much worse. Versions prior to 5.2 provide rather weak native threading. In some circumstances, I/O-intensive threads are able to get an unfair amount of CPU time, thus keeping other threads from executing as quickly as they should. Given the I/O-intensive nature of some database queries, this has a rather devastating affect on MySQL."
(EDIT : by the way, I don't know what the thread handling scheme is, in Mac OS X. Does it use an approach similar to FreeBSD? Anyway, seems like OS X suffers the same threading performance problems than FreeBSD)
In the case of MySQL I thought this was to do with the fsync() differences between linux and OSX. ie. nothing to do with kernel threading
The OS does seem to have a problem in that area. It only manafests itself in Database operations of this nature. I've heard that Oracle worked around it.
Quoted from the book "High Performance MySQL", chapter 6, "Server Performance Tuning" : "This all means that the first bottleneck you're likely to encounter is disk I/O."
However, thread handling also seems to be an issue, and it seems to be a FreeBSD flaw : "Another popular free operating system, FreeBSD, has threading problems that are much worse. Versions prior to 5.2 provide rather weak native threading. In some circumstances, I/O-intensive threads are able to get an unfair amount of CPU time, thus keeping other threads from executing as quickly as they should. Given the I/O-intensive nature of some database queries, this has a rather devastating affect on MySQL."
(EDIT : by the way, I don't know what the thread handling scheme is, in Mac OS X. Does it use an approach similar to FreeBSD? Anyway, seems like OS X suffers the same threading performance problems than FreeBSD)
Hope this will help...
This issue is the thread handling. Disk I/O hasn't been a problem except for Firewire 800 on the Powermac. I forget which, either the reads or writes are slow.
Comments
Originally posted by melgross
If they are intended to use the new 7448 cpu's from Freescale, then that could be why we haven't seen them.
Apple's fortunes have waxed and waned depending on the ability of their suppliers to deliver what they have promised on time and at speed. That's why Apple is leaving them after all.
These chips are delayed. That could be why Jobs canceled his keynote at the Paris fair.
And you know this because?...
Freescale's press release in June said they'd not be in volume production till October. Perhaps Jobs was hoping they'd be ready earlier - I know WE all are.
Wait till October, then bash them.
Aside from that, we've no idea if this update is going to include DDR2, SATA or other features rumoured in the Intrepid2 chipset. Maybe that's late. ie. we don't know. But bashing Freescale for not delivering early is a but harsh.
Originally posted by aegisdesign
And you know this because?...
Freescale's press release in June said they'd not be in volume production till October. Perhaps Jobs was hoping they'd be ready earlier - I know WE all are.
Wait till October, then bash them.
Aside from that, we've no idea if this update is going to include DDR2, SATA or other features rumoured in the Intrepid2 chipset. Maybe that's late. ie. we don't know. But bashing Freescale for not delivering early is a but harsh.
I've been dealing with Powerlogix recently. I've bought several boards from them. They've got boards waiting on the 7448's. A month or so ago they had a meeting with Freescale about the 7448's and the 1.4GHz 7457's. They were told that the 7457's would be delayed slightly (the boards just came out). They were also told that the 7448's might be delayed slightly as well.
I've also read this the past week elsewhere.
Even if the chips were available NOW, it would take time to build them in. The question is; what does volume mean? If the chips were ready, Apple could have recieved 20 thousand already. That wouldn't be considered as volume, but would be enough to prepare an initial shipment. If the chips were then delayed (usually because of an early production glitch), Apple would have to pospone their introduction.
Originally posted by sunilraman
boy this is so so sad if the whole apple expo was f*cked because of freescale, surprise, yet again, dissapointing apple. and jobs having to move the nano intro up to sep 7th to override the motorola itunes phone nonsense. what fucking deadweights. can you tell my sour mood today?
Nah. You seem pretty much the same.
It must be the humidity.
okay, back on topic for a sec:
so it's still very up in the air about the powerbooks at apple expo huh? i think with nano and .mac updates and apple clearing this quarter with strong financial results (most likely) ... we'll see new powerbooks and powermacs oct/nov. you heard it here first
*hugs 1.5 15" and dreams of her younger sister in 12 months*
Originally posted by IntlHarvester
I can't see any particular reason why OS X software would be slower on CPU benchmarks than Windows software. If a company is building with the Intel compiler on Windows, they'll probably do so on MacOS as well. Also, GCC is apparently much better on x86 - within 20% of the Intel compiler according to some testing I've seen - and probably just as fast as the widely used MS compiler.
The areas of concern would be:
1) Software that still uses QuickDraw, because apparently that's considerably slower than the new APIs. OTOH, Windows GDI will probably be running in a similar penalty mode under Vista.
2) Games, particularly DirectX games that run through an OpenGL translation layer. Also the OS X Doom3 benchmarks supposedly pointed OpenGL drivers out a weak point. However, nobody buys Macs for the FPS, so no biggie.
3) Server benchmarks, such as I/O or multiprocessing, where OS X hasn't always shown well.
1) QuickDraw has been deprecated for quite a long time now, and I've read somewhere (really don't remember the link, sorry) that Apple didn't intend to keep QuickDraw in Mac OS X after 2007-2008. I guess some dinosaur apps will have to be rewritten a little, and that's not bad!
2) 3D cards drivers for the Intel Macs will certainly share a lot of code with the PC version. Nvidia cards drivers for Intel builds of Linux are already quite good. So let's be optimistic in the GL field! Plus Vista will only provide GL support through an emulation layer, leading to crappy performance.
3) OS X will never lead on I/O performance, as it is a microkernel-based operating system. On multiprocessing, however, Tiger has brought a nice speedup, thanks to finer grain kernel locking etc... That's not bad news!
Originally posted by sunilraman
okay, back on topic for a sec:
so it's still very up in the air about the powerbooks at apple expo huh? i think with nano and .mac updates and apple clearing this quarter with strong financial results (most likely) ... we'll see new powerbooks and powermacs oct/nov. you heard it here first
I agree with you. Incremental bumps in oct/nov is all we're likely to see for Powerbooks. Dual-core 970MP is still possible for the same timeframe on Powermacs.
"...QuickDraw has been deprecated for quite a long time now..."
yes, goodbyes to quickdraw.
"...Nvidia cards drivers for Intel builds of Linux are already quite good..."
for some reason earlier i got screen corruption but in the past few weeks after using Suse9.3 online update to get the nvidia driver, no problems at all, plus nvClock overclocking on linux has been decent. quake2 demo sdl opengl linux is flawless on my linux setup. yes its quake2 but running at 1280x1024, 16xAF 16xAA.
"So let's be optimistic in the GL field! Plus Vista will only provide GL support through an emulation layer, leading to crappy performance..."
that's weird, that means microsoft is betting heavily and targeting the gaming market what about 3d apps that use PC windows workstations for maya/3dmax/etc? how are they going to handle the openGL hit on vista? or have alias and discreet figured a way to get around this problem... curious...?
"OS X will never lead on I/O performance, as it is a microkernel-based operating system. On multiprocessing, however, Tiger has brought a nice speedup, thanks to finer grain kernel locking etc... That's not bad news!"
well, it's good news for consumer desktop and enterprise desktop possibilities... but what does this mean for os X server? given that, as the benchmarks suggest, os X server gets creamed by say, linux-on-opterons for mysql...??
Originally posted by gsxrboy
...*hugs 1.5 15" and dreams of her younger sister in 12 months*
and people think i'm the one with problems here
Originally posted by sunilraman
well, it's good news for consumer desktop and enterprise desktop possibilities... but what does this mean for os X server? given that, as the benchmarks suggest, os X server gets creamed by say, linux-on-opterons for mysql...??
I presume you mean the Anandtech MySQL benchmark?
Those have been debunked quite a lot now.
See http://dev.mysql.com/doc/mysql/en/news-4-1-9.html
The comment on the bottom of the changes is from Dominic Giampaolo at Apple and explains why it is slower - extra safe flushing on OSX. Linux doesn't flush the data from a drive's cache so will always be faster.
Secondly, some drives don't honour an F_FULLSYNC and simply tell the OS that they've done it. Apple don't ship drives that lie so in a benchmark test you have to be careful comparing one drive to another.
So if you want speed - go Linux but be sure you've always got power to your server or it may corrupt the database. Worse, if your drive lies, MySQL might think it's done it's flush, power goes and when you're back up MySQL thinks everything is ok but the drives didn't finish writing.
If you want safe data - go OSX.
I suspect there's something MySQL could do to improve performance and match OSX's scheme of safe writing of data, such as writing less often but at the moment it's more reliant on the Linux methodology of writing often and presuming the drives don't lie.
I'd hope someone at Apple would address MySQL performance directly as it's pretty important these days for a server.
Originally posted by sunilraman
Originally posted by The One to Rescue
but what does this mean for os X server? given that, as the benchmarks suggest, os X server gets creamed by say, linux-on-opterons for mysql...??
As I told you, Mac OS X now lags behind Linux, and will always lag behind Linux, in the field of I/O performance. That's an architectural choice : Mac OS X is based on the Mach microkernel. A microkernel only handles very primitive low-level tasks, such as memory allocation, multitasking, etc... Higher-level services are booted out of the kernel. That's very clean, and it really makes sense, but it's also rather slow.
Linux is a monolithic kernel : the filesystem and a lot of other stuff is included right into the very kernel. Awful architecture, fast execution.
By the way, the "good news" I was talking about was the SMP boost on Tiger. I was not talking about I/O. I/O performance still suck and that's a problem for Mac OS X Server.
nah, seriously aegis and rescue, thanks for clarification on that. now at least i have a clearer picture on mysql on os x versus linux. and this microkernel thing....
Originally posted by melgross
It isn't the microkernal that's the problem. The way the OS passes and releases threads seems to be the problem. Basically it takes too many steps. I've been told that Apple is working on it, but that it might take a while.
I never said that the microkernel was the cause of all the speed issues in OS X. However, it really slows down the I/O part. Now i don't know if that's the main bottleneck on MySQL, but that sure is one, since database processing uses mass storage like a bitch.
Originally posted by The One to Rescue
I never said that the microkernel was the cause of all the speed issues in OS X. However, it really slows down the I/O part. Now i don't know if that's the main bottleneck on MySQL, but that sure is one, since database processing uses mass storage like a bitch.
Mass storage I/O has very little to do with this. It's the transactions carried out in the database as it works through the OS. Thread handling is where the problem is found.
Originally posted by melgross
It isn't the microkernal that's the problem. The way the OS passes and releases threads seems to be the problem. Basically it takes too many steps. I've been told that Apple is working on it, but that it might take a while.
In the case of MySQL I thought this was to do with the fsync() differences between linux and OSX. ie. nothing to do with kernel threading
Originally posted by melgross
Mass storage I/O has very little to do with this. It's the transactions carried out in the database as it works through the OS. Thread handling is where the problem is found.
Quoted from the book "High Performance MySQL", chapter 6, "Server Performance Tuning" : "This all means that the first bottleneck you're likely to encounter is disk I/O."
However, thread handling also seems to be an issue, and it seems to be a FreeBSD flaw : "Another popular free operating system, FreeBSD, has threading problems that are much worse. Versions prior to 5.2 provide rather weak native threading. In some circumstances, I/O-intensive threads are able to get an unfair amount of CPU time, thus keeping other threads from executing as quickly as they should. Given the I/O-intensive nature of some database queries, this has a rather devastating affect on MySQL."
(EDIT : by the way, I don't know what the thread handling scheme is, in Mac OS X. Does it use an approach similar to FreeBSD? Anyway, seems like OS X suffers the same threading performance problems than FreeBSD)
Hope this will help...
Originally posted by aegisdesign
In the case of MySQL I thought this was to do with the fsync() differences between linux and OSX. ie. nothing to do with kernel threading
The OS does seem to have a problem in that area. It only manafests itself in Database operations of this nature. I've heard that Oracle worked around it.
Originally posted by The One to Rescue
Quoted from the book "High Performance MySQL", chapter 6, "Server Performance Tuning" : "This all means that the first bottleneck you're likely to encounter is disk I/O."
However, thread handling also seems to be an issue, and it seems to be a FreeBSD flaw : "Another popular free operating system, FreeBSD, has threading problems that are much worse. Versions prior to 5.2 provide rather weak native threading. In some circumstances, I/O-intensive threads are able to get an unfair amount of CPU time, thus keeping other threads from executing as quickly as they should. Given the I/O-intensive nature of some database queries, this has a rather devastating affect on MySQL."
(EDIT : by the way, I don't know what the thread handling scheme is, in Mac OS X. Does it use an approach similar to FreeBSD? Anyway, seems like OS X suffers the same threading performance problems than FreeBSD)
Hope this will help...
This issue is the thread handling. Disk I/O hasn't been a problem except for Firewire 800 on the Powermac. I forget which, either the reads or writes are slow.