Don't you also have a single hardware supplier if you go with Suns? Or with a lot of IBM boxes?
But you can port an app written for Linux, using Linux/GNU libraries, from hardware platform to hardware platform very easily.
I doubt many companies run Linux on their Sun boxes. And in general, porting *nix apps to Mac OS X isn't that hard either.
And the whole point about x86 boxes is that you can change supplier whenever you feel like it - there are even multiple chip suppliers. If the AMD fab burns down, well there is still Intel, VIA, Transmeta...
That's why I questioned your Sun/Sparc example. Sure, other companies than Sun also make Sparc processors, but they don't necessarily sell the boxes or other components. Same with IBM and a lot of their servers.
Have to disagree with you here - what does an Apple back end have to offer someone doing huge distributed computations that Linux or BSD on x86 (or Sparc, or anything else you care to name) except increased price and a single hardware supplier?
Don't you also have a single hardware supplier if you go with Suns? Or with a lot of IBM boxes? XServe's are actually quite price-competitive in their market, especially due to their storage capacity and I/O throughput (disk network) combined with hot swappable drives and a 1U form factor. With a PPC970, the processing power could increase enough to make them quite competitive in that field as well (well, apart from in genetics, where thanks to altivec and extremely optimized code they already blow pretty much anything else out of the water, but that isn't possible for a lot of other server tasks of course).
The Xserves will probably find a home in smallish companies who need a web server that is pretty reliable, or a DB server for a couple of hundred users at most.
Even the current XServes can already handle a lot more than that. And if you didn't mean to imply they can't, then I don't understand your reasoning behind this. Too expensive = will only be used for small setups so their higer cost can be recouped even less?
You don't. Sure, you can, but it's completely unsupported and your programs may break with every new release of Darwin/Mac OS X. Here's the official answer from an Apple engineer that I got (login/pw = archives/archives).
The rest of the world will probably follow in the next few days. It almost always takes a while for the international sites to be updated. And regarding your dollor comment: they did slash the Canadian prices a lot more than the US prices, so I expect the same for other countries.
I don't see why so many people are making such a big deal about this. Everyone who has actually used wireless networks knows that you can reach about half of the advertised speed maximally. There was even a Slashdot article last month about how they're going to try to improve this in the 802.11n standard.
Bottom line: all they're doing is giving everyone a reality-check and pointing out that even though the device itself transmits at 54mbps, you can never reach an actual throughput even near that speed (just like you can never get 11mbps with 802.11b).
I think that pervasive availability of 64-bit computing has the potential to allow the reinvention of HCI. We can't find out until we go there. Its quite possible that "most" of the application we're running in 10 years will benefit significantly from 64-bit integer operations. (I put "most" in quotes as you did, because by your logic "most" of what we do today didn't really benefit from the transition from 16 to 32-bit, but from clock speed increases.
That is not true. At the time the transition from 16 bit to 32 bit was made in the PC world, everyone was already using 32 bit addressing with the segment:offset notation. 64kb was not enough for any but the smallest of programs. It's not like almost no program currently fits in 2 or 2.5GB anymore and I don't see that barrier becoming a limiting factort for most programs (with programs != OS, because e.g. Mac OS X already has a problem with exhausting its address space if you have a lot ram in some cases) in the near future.
I'm not advocating "2 GB should be enough for everyone", because I do aknowledge there are applications that can easily use a lot more memory. I just don't think many of those applications are situated in the consumer space. I'm also not advocating against going 64 bit (especially not if that 64 bit processor can run 32 bit programs more efficient than current 32 bit processors, although that has nothing to do with the processor being 64 bit of course). I just wanted to make sure that people don't think that recompiling a program for 64 bit will suddenly somehow magically almost double the performance of said application.
Anyway, it all comes down to the following quote, which is what I took issue with and have been ranting to the contrary about:
The only real advantage of being 64 bit will be the ability to address more memory.
We don't know what all the real advantages will be, so we certainly can't say that additional memory will be the only one
I should have added "with regard to your recompiled Adobe photoshop and after effects and most other applications you regularly use". Back when the change from 16 to 32 bit happened in the PC world, everyone was bumping against all sorts of 16 bit limits. You could easily have more than 65536 records in a database, need more than 64k (or 640kb, or 1MB) of ram, wanted to address video memory without having to sacrifice a segment register for it, etc. I just don't see this happening currently with the 32 bit quantities we currently have at our disposal (except in some specific cases like the ones you mentioned, most having to do with large files access/processing), which is why I think the transition to 64 bit won't be such a revolution for PC's as the one to 32 bit was (although for the Mac this point is more or less moot, as the m68k was 32 bit from the start, although it had only a 24 bit address bus at first).
Chill out man, there's no need to lower yourself to insulting someone because you disagree. I nowhere said that having a 64 bit address space wasn't useful (on the contrary). And of course, to be able to work with 64 bit addresses, you need 64 bit operations. I was merely arguing that most consumer level apps can't be improved by changing their core logic from 32 bit to 64 bit integer operations and that I don't see that changing now that there will be 64 bit consumer computers available, because the calculations that these applications do don't require or simply don't work on such large values. I also don't see the fact that 64 bit operations will be natively supported, enable a whole new range of applications that were previously not feasable because doing 64 bit operations would require 2, 3 or more instructions instead of 1.
Your two main examples (memory mapped IO and filesystem code) are both OS-specific. Yes, you can consider the OS as just another application running on your system and it's obvious that improvements made to the OS will benefit every application, however I hope you agree that when talking about "consumer level apps", few people will consider operating systems. I don't even want to know what you'd call me if I'd start talking about "the Mac OS X application".
Also note the "most" I used everywhere in my posts. I never said there would be no cases (such as the database example you mentioned) where native 64 bit operations can come in handy.
Being 64bit also brings you any additional benefits that the new processor brings, such as additional registers/pipelines/etc
You've got that backwards. It's actually "Getting a new processor may give you several new advantages, such as being 64 bit, getting additional registers, pipelines etc". This has nothing to do with the 64 "bitness" of the processor.
This is why with Opteron even a 3D app will benefit for native compilation, the doubling of the number of registers, including doubling the xmm registers which are so important these days
Since the G4 already has 32 integer, 32 floating point and 32 vector registers, the PPC 970 does not add any registers since there are already plenty.
I would guess that the 970 will offer similar improvements in addtion to the larger address space.
You may want to read the last sentence of my original post again.
And how exactly does this contradict the statement that you quoted? Also note that wide datapaths have nothing to do with the fact that the PPC 970 is a 64 bit processor. After all, the G4e already has a 256 bit wide path to its L3 cache and a 64 bit bus to main memory. The PPC 970 does support a much better bus architecture than the G4(e), but that has nothing to do with it being a 64 bit processor.
PS: I think you're barking up the wrong tree here. I'm not trying to bash the PPC 970 in any way, I'm just trying to prevent people from thinking that going from a 32 to a 64 bit processor will suddenly make everything automatically faster when their programs are compiled into 64 bit versions. I personally think the 970 is great and I'm looking forward to replace my aging G4/400 with one of these puppies.
Did you ever think that the reason there are few consumer level apps that will take advantage of 64 bit architectures is that nobody has a 64 bit PC yet?
No. And I still don't think that's the reason. How can you make a word processor better using 64 bit code instead of 32 bit code? A spreadsheet? A web browser? An email client? A terminal emulator? A shell? A pdf viewer? I stand by my original point that most consumer apps don't need 64 bit operations.
Some video/image editing applications may be able to get a small win out of it, but I don't think it will help a lot, since in general they operate on 8 (single color channel) or 32 (3 color channels+alpha) bit quantities. For that kind of operations, the vector unit shines. You can use the regular integer registers as well, but then you get some overhead because of all the masking that's necessary to keep the separate channels from overflowing into the next one. Of course it's possible (after all, that's all there was before altivec etc) and can be combined with the usage of the vector unit, but I doubt it will deliver a lot of extra performance over a 32 bit processor.
Having extra memory available will help everyone (if only because it can be used as a disk cache if no application needs it), but a 64 bit integer unit is not necessary or even helpful in most cases (except for being able to address said memory). As someone else in this thread already remarked, making a program 64 bit may actually make it slower instead of faster if you do it just for bragging rights or because it seems cool.
That's not PPC970 specific, as the current G4(e) also has a vector unit (or 4, depending on how you look at it). Vector operations will indeed be faster, but that's mainly due to the faster memory bus.
Being 64 bit will not help 3D apps any better than 2D apps. The only real advantage of being 64 bit will be the ability to address more memory. This will be advantageous for any application (2D, 3D, database,...) that can use so much memory. The reason is that most applications simply do not yet require many 64 bit integer operations, so the fact that a 32 bit processor executes those more slowly than a 64 bit one doesn't really matter.
The 970 will be faster for most applications not because it is 64 bit, but mainly because it runs at a higher clock speed and has a much wider/faster memory interface. Some other architectural decisions (deep pipeline with aggressive optimization logic) will help somewhat as well, probably.
After all, they have that "high speed L3 cache" using DDR memory that interfaces to the processor at high speed. Why they couldn't extend that pipe out to main memory at the very same bandwidth is anyone's guess.
L3 cache is limited to 4MB, so there are probably not enough address lines on that bus (unless you want to make a system with only 4MB of memory of course). The main memory interface of the 7450 (and not 7440 like the article states: that one is only used in lower-end machines like the iMac and eMac) is what Apple has to use to go to the main memory, and it's that one that's so limited.
If you want to play a DVD in QuickTime, you have to pay other $20.
Who on earth watches DVD's in Quicktime Player? What do you think/Applications/DVD Player is for? It plays DVD's full screen and on top lets you view the menu's and extra's.
I LOVE the keyboard shortcuts in Mplayer, especially navigating forward and backward with the arrow keys, I can skip whathever stuff I want withot using the mouse.
Quicktime Player does support arrow keys for navigation. It doesn't allow you to skip large parts however (and there doesn't seem to be a shortcut that allows you to do that), it only does a fast-forward which is indeed annoying sometimes.
Another shortcoming of QuickTime: if you want to play an Xvid or Divx file you have to convert it first.
If it's embedded in an avi and has an mp3 audio track, at least.
Also, unlike Videolan, QuickTime does not play.ogm (ogg) movies
That said, I by no means want to say mplayer and video lan client are bad, I use them regularly myself (for divx/xvid avi's with mp3 audio tracks). They're not as stable as Quicktime Player though, and fast-forwarding or rewinding doesn't always work (there seem to be points in some movies you just can't get by except at normal playing speed, both in mplayer and vlanc). Switching from full screen back to windowed mode doesn't always work either in vlanc (afterwards, the window is often black until you switch back to fullscreen mode).
Re:Everything can be related to math.
on
Origami and Math
·
· Score: 1
Lo'pital's rule
If you write his name like that, it looks more like Klingon than like French:) FWIW, it's "de L'Hôpital" (literally translated "from the hospital"). Now why does this all connect so well with this story? Ladies and gentlemen, I think we have a seer in the audience!
I find the Windows system actually annoying. Either you get easy accents and annoying stand-alone quotes, or you get easy stand-alone quotes and no accents. Both doesn't seem to be possible (I don't consider "+space easy).
It's also already illegal in Belgium. Dutch and French version available online (article 14 is the relevant one, it says (translated):
Par 1. The usage of electronic mail for publicity is prohibited without prior, free, specific and informed consent of the receiver of the messages. [the "King" can grant exceptions to this rule when advised to do so by both the minister of Justice and the minister of Economic Affairs]
Par 2. When sending publicity via electronic mail, the provider of said service takes care of the following:
He provides clear and understandable information about the right to resist receiving ads in the future.
He points to a means that is fit to exercise this right efficiently via electronic way and provides said means.
[The King etc. define the modalities according to which the providers have to respect the will of the recipient]
Par 3. When sending publicity via electronic mail, it is prohibited:
to use the address or identity of a third party
to forge or hide information that allows one to recognize the source of the electronic mail or the way it traversed.
Par 4. The provider must deliver the proof that the publicity via electronic mail has been requested.
The punishment for breaking article 14 is a penalty of 250 to 25000 Euro. Not bad, I'd say. Breaking of said law can be determined by civil servants of the Ministry of Economic Affairs (and the police obviously). Not bad, I'd say...
Sure, assuming Apple don't end up with a near monopoly. This kind of thing suffers a classic network effect - can you see people joining 20 or 30 different download services to get their music?
I think the big point you're missing here is that you don't have to "join" Apple in any case. You don't pay a subscription fee, they just have your credit card info and address. I don't see any way they could make it difficult for you to join another service.
Obviously, it's rather unlikely they'll add support for other music selling services to iTunes, but nothing prevents those other businesses to come out with their own music player that superior to iTunes so that everyone would switch in droves.
As others already have said, the gains have nothing to do with the apps being 64bit. Most gains are realised by the much higher memory bandwidth available to the 970 (the G4 is quite good, but for some reason Motorola never produced a G4 that could handle a DDR interface).
It's Windows and Mac (both classic and X). I think the main reason that it is (was) used a lot by game developers, is that it's easy to license (for reasonable terms), easy to include in your code and it doesn't require a separate install (it's just a shared library that you link to your program, unlike, say, Quicktime).
it seems the money is going to Apple and the RIAA, not artists. Just adding another middleman.
Not another middleman, with cd's there's the cd manufacturers, distributors and the retailers, so in fact there's less middlemen in this scenario. I guess the record companies get just as much for songs sold through this service than what they get for cd's sold through traditional channels (maybe slightly more in some cases and slightly less in others).
I doubt the end result will be much different for the artists themselves (ie. generally still screwed, but they get something instead of nothing)
You can select both a quality level and a target bitrate when exporting to AAC in Quicktime. It may work like the 3ivx codec in that regard (see this page for an explanation). The bitrate is just a target (like with ABR), but the quality level may increase the bit rate if it turns out the target bitrate cannot satisfy it.
The fact that it doesn't increase anymore after a certain size, may also be similar to the way 3ivx works (see the comment by Stux in that thread)
Slashdot Mirror
You don't. Sure, you can, but it's completely unsupported and your programs may break with every new release of Darwin/Mac OS X. Here's the official answer from an Apple engineer that I got (login/pw = archives/archives).
The rest of the world will probably follow in the next few days. It almost always takes a while for the international sites to be updated. And regarding your dollor comment: they did slash the Canadian prices a lot more than the US prices, so I expect the same for other countries.
The eMac had indeed a horrible problem in the beginning (video would die a lot). This has been solved however (see bottom two posts here.
Bottom line: all they're doing is giving everyone a reality-check and pointing out that even though the device itself transmits at 54mbps, you can never reach an actual throughput even near that speed (just like you can never get 11mbps with 802.11b).
I'm not advocating "2 GB should be enough for everyone", because I do aknowledge there are applications that can easily use a lot more memory. I just don't think many of those applications are situated in the consumer space. I'm also not advocating against going 64 bit (especially not if that 64 bit processor can run 32 bit programs more efficient than current 32 bit processors, although that has nothing to do with the processor being 64 bit of course). I just wanted to make sure that people don't think that recompiling a program for 64 bit will suddenly somehow magically almost double the performance of said application.
I should have added "with regard to your recompiled Adobe photoshop and after effects and most other applications you regularly use". Back when the change from 16 to 32 bit happened in the PC world, everyone was bumping against all sorts of 16 bit limits. You could easily have more than 65536 records in a database, need more than 64k (or 640kb, or 1MB) of ram, wanted to address video memory without having to sacrifice a segment register for it, etc. I just don't see this happening currently with the 32 bit quantities we currently have at our disposal (except in some specific cases like the ones you mentioned, most having to do with large files access/processing), which is why I think the transition to 64 bit won't be such a revolution for PC's as the one to 32 bit was (although for the Mac this point is more or less moot, as the m68k was 32 bit from the start, although it had only a 24 bit address bus at first).Your two main examples (memory mapped IO and filesystem code) are both OS-specific. Yes, you can consider the OS as just another application running on your system and it's obvious that improvements made to the OS will benefit every application, however I hope you agree that when talking about "consumer level apps", few people will consider operating systems. I don't even want to know what you'd call me if I'd start talking about "the Mac OS X application".
Also note the "most" I used everywhere in my posts. I never said there would be no cases (such as the database example you mentioned) where native 64 bit operations can come in handy.
PS: I think you're barking up the wrong tree here. I'm not trying to bash the PPC 970 in any way, I'm just trying to prevent people from thinking that going from a 32 to a 64 bit processor will suddenly make everything automatically faster when their programs are compiled into 64 bit versions. I personally think the 970 is great and I'm looking forward to replace my aging G4/400 with one of these puppies.
Some video/image editing applications may be able to get a small win out of it, but I don't think it will help a lot, since in general they operate on 8 (single color channel) or 32 (3 color channels+alpha) bit quantities. For that kind of operations, the vector unit shines. You can use the regular integer registers as well, but then you get some overhead because of all the masking that's necessary to keep the separate channels from overflowing into the next one. Of course it's possible (after all, that's all there was before altivec etc) and can be combined with the usage of the vector unit, but I doubt it will deliver a lot of extra performance over a 32 bit processor.
Having extra memory available will help everyone (if only because it can be used as a disk cache if no application needs it), but a 64 bit integer unit is not necessary or even helpful in most cases (except for being able to address said memory). As someone else in this thread already remarked, making a program 64 bit may actually make it slower instead of faster if you do it just for bragging rights or because it seems cool.
That's not PPC970 specific, as the current G4(e) also has a vector unit (or 4, depending on how you look at it). Vector operations will indeed be faster, but that's mainly due to the faster memory bus.
The 970 will be faster for most applications not because it is 64 bit, but mainly because it runs at a higher clock speed and has a much wider/faster memory interface. Some other architectural decisions (deep pipeline with aggressive optimization logic) will help somewhat as well, probably.
No, it predates MPEG-4 by quite a long time. It's not MPEG4-compliant in any way afaik.
That said, I by no means want to say mplayer and video lan client are bad, I use them regularly myself (for divx/xvid avi's with mp3 audio tracks). They're not as stable as Quicktime Player though, and fast-forwarding or rewinding doesn't always work (there seem to be points in some movies you just can't get by except at normal playing speed, both in mplayer and vlanc). Switching from full screen back to windowed mode doesn't always work either in vlanc (afterwards, the window is often black until you switch back to fullscreen mode).
I find the Windows system actually annoying. Either you get easy accents and annoying stand-alone quotes, or you get easy stand-alone quotes and no accents. Both doesn't seem to be possible (I don't consider "+space easy).
Obviously, it's rather unlikely they'll add support for other music selling services to iTunes, but nothing prevents those other businesses to come out with their own music player that superior to iTunes so that everyone would switch in droves.
As others already have said, the gains have nothing to do with the apps being 64bit. Most gains are realised by the much higher memory bandwidth available to the 970 (the G4 is quite good, but for some reason Motorola never produced a G4 that could handle a DDR interface).
It's Windows and Mac (both classic and X). I think the main reason that it is (was) used a lot by game developers, is that it's easy to license (for reasonable terms), easy to include in your code and it doesn't require a separate install (it's just a shared library that you link to your program, unlike, say, Quicktime).
I doubt the end result will be much different for the artists themselves (ie. generally still screwed, but they get something instead of nothing)
The fact that it doesn't increase anymore after a certain size, may also be similar to the way 3ivx works (see the comment by Stux in that thread)