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.
Quad Processor Intel Mac?
- Thread starter MacBytes
- Start date
- Sort by reaction score
Mr Maui said:
1. You have it backwards. Cocoa apps will be the easiest to port. Carbon apps not written in Xcode will require the most effort to port.
2. The Adobe apps are still Carbon, as far as I know, so it'll take more effort than most. Adobe was pretty slow in porting their apps to OS X. I'd imagine the same for porting to Intel. There's a reason Steve demoed photoshop on Rosetta.
3. The toughest apps to port will be apps that rely on Altivec for performance. Rosetta does not run Altivec apps, nor any apps that require G4 or G5. So a lot of pro apps will need to be re-written if they are to run at all on Intel. Not a trivial task.
To both of you, I said 'legit' developers.
I'm assuming the company you work for jettredmont is 'legit'.
I'm talking about 'Garry the Geek' sitting in his mom's basement hacking OS X then posting the images on the net.
And didn't I finish with 'But anything is possible I guess'?
I'm not talking about businesses, I'm talking about individuals.
Jeez.
What INDIVIDUAL has a quad Xeon server sitting around, just for kicks?
I'm assuming the company you work for jettredmont is 'legit'.
I'm talking about 'Garry the Geek' sitting in his mom's basement hacking OS X then posting the images on the net.
And didn't I finish with 'But anything is possible I guess'?
I'm not talking about businesses, I'm talking about individuals.
Jeez.
What INDIVIDUAL has a quad Xeon server sitting around, just for kicks?
All this talk about a quad system is ludicrous. It if anything is a dual processor system with 2 dual core chips.
Depends on how portable the code is right now.jettredmont said:
I've worked on projects designed to be massively cross-platform compatible. That kind of code can usually be ported in a matter of hours (followed by a few weeks of QA testing, of course.)
For example, just for kicks, we once made a release for Windows/x86 that used X11 as the GUI interface. It was a real easy port - just set the appropriate platform-defining macros and rebuild.
Since companies like Adobe already have shipping x86 and Mac-PPC code, it may not be all that hard for them to mix-and-match the code-base by enabling x86-specific code along with Mac APIs and the Mac GUI. Assuming their build environment was engineered to be this portable, of course.
This is the big deal. Even the most portable code still needs to be tested, because there are always unexpected things. For instance, I can guarantee you that the x86 port of OS X will not have the exact same bugs as the PPC port of the same version. Which means workaround code needed by the app on one platform will have to be absent on the other.jettredmont said:
Like the Java mantra - write once, test everywhere.
Some companies can move pretty fast when they are suitably motivated. I know of several shareware vendors which can knock out bug fixes within hours of the bug report. Assuming a reasonably fast testing cycle, they may be able to get new ports out within a few days, if they want to.jettredmont said:
Forgive my mis-stating of information as it was not intentional. I am not an application expert nor computer code expert. Cocoa, carbon, etc. are merely words to an average Joe like me, and I apologize for not specifically knowing the difference. Many others who are experts, or at least more educated in these areas, know this better than I ... I confess. I just remember SJ saying that most current apps would be relatively easy to port, slightly older apps would port slower and require some code changes, but should still port with relative ease, albeit slower than native Cocoa apps, and only the oldest of apps would require that they be rewritten completely into whatever the current code is (something that developers should probably do to keep up with the times anyway ... IMO). If Mathematica (or whichever app they demonstrated at WWDC) could be ported in a day or two by one or two guys (the head of the company and a techie), then large companies like Adobe, etc., with full teams of software developers at their disposal, should be able to port their major software packages with relative ease and quickly make the necessary modifications to their code to make the transition. WWDC was many months ago and I suspect that Adobe and the like are not waiting to shift their software to Intel setup until after the boxes themselves are available. Please forgive any mis-statement of terms or facts.dongmin said:
igetbanned said:
igetbanned said:
Since I never signed an NDA I have no problem confirming the above statements. I recently went on an interview at an Intel location with the group who does the processor testing. In thier testing labs they showed me the next gen processors and logic boards which are slated to come out in the next 9 to 18 months. The boards had sockets for more than two processors. Primarily, they are server products, however, it sound like there could be other applications for these multi-processors systems.
A little side note, the reason they interviewed me was due to my past experience with Apple an as such if I took the position it required interfacing with some of thier key customers on their testing requirements. I got the feeling whatever they were working on was heading Apple's way.
Carbon apps will port fairly quickly. Carbon still exists on x86.dongmin said:
Not using Xcode is the big deal here, because MetroWerks won't be shipping an x86 version of Code Warrior (since they sold their x86 compiler division off many years ago.) If your app depends on their PowerPlant libraries, you'll have to re-work it to no longer need them. That is what will take a long time.
The longest porting job, however, will be pre-Carbon apps. The ones that today require the Classic environment. They're not going to port over at all until they're ported up to Carbon. Depending on how badly-written the app is, this may be a nightmare job.
But if they're written using only the Mac APIs and are not using third-party toolkits, then they should quickly port over to Xcode and recompile for x86 without much work.dongmin said:
That slowness was because they were porting pre-Carbon apps to Carbon. And yeah, they took an insanely long time. The Carbon libraries were available all the way back in the days of System 8!dongmin said:
Maybe, maybe not.dongmin said:
Apple has had their Accelerate Framework out since Mac OS 10.3. Apps that use it for all their AltiVec access won't have to port that code at all. Ditto for apps that indirectly access AltiVec via other Apple object classes, APIs and frameworks.
Code that directly makes AltiVec calls will have to be ported. But Apple has already published guidelines for this. (Either use conditional compilation and macros to selectively compile code as AltiVec or SSE, or port the code to the Accelerate Framework.) It shouldn't be hard to port this, although it may be time consuming, depending on how the app is organized.
Shouldn't that be on Page 2?
It's either a fake or a screenshot of a pirated Tiger copy running on some quad Xeon box
Or ...
There is a quad Xeon Xserve coming...
Next Tuesday !
Or Wednesday 11!!1eleven!!
Go to bed, folks, nothing to see here.
It's either a fake or a screenshot of a pirated Tiger copy running on some quad Xeon box
Or ...
There is a quad Xeon Xserve coming...
Next Tuesday !
Or Wednesday 11!!1eleven!!
Go to bed, folks, nothing to see here.
This is nothing new. The Pentium Pro supported up to 4-way multiprocessing. The Xeon has always supported up to 8-way multiprocessing (although not all of the processors shipped have this feature enabled.)Maestro64 said:
AMD's Opteron also supports up to 8-way multiprocessing.
Quad-processor motherboards (mostly using Xeons and Opterons) are easy to buy today.
Systems based on more than one CPU are typically only used in servers, but that's only because most people don't see the need for more than one CPU. Which is just as true in the Mac world as it is in the PC world. (Which is why, for instance, Apple doesn't have any desire to ship dual-CPU iMacs.)
if it's dual core, the software would probably count each core as a physical processor, since they pretty much are. the hyperthreading would show up as non-physical.liketom said:
so this system (if not fake) is likely a dual core, dual processor, hyperthreading intel mac
strydr said:igetbanned said:
What in the world did you have 3 quad Xeons servers for?
Just curious.
You're not the average 'geek' I'm talking about.
(And you do know you wasted your money on them.....don't cha
