AltiVec 2?
I have, over the years, and recently, pooh-poohed any rumors about an "AltiVec 2," so I suppose it's only fitting that I post the first really firm evidence of such a thing (courtesy of stingerman@Ars) and publicly eat crow. 
IBM discusses shortcomings of AltiVec. The link is to the second page of a performance comparison between Mot's and IBM's AltiVec implementations. The interesting stuff (for us) is the discussion of autovectorization right before the summary, and the discussion of the shortcomings in the summary.
The additions proposed are more minor than most of the AV2 rumors (i.e., there is no call for 4-way 64-bit SIMD, just a way to store 64-bit values), but they're additions to the ISA, and thus significant going forward.
None of this means that IBM will ship such a beast, and there are genuine concerns if they do—if Motorola decides not to adopt their improvements, then AltiVec has its first really serious fracture in terms of implementations, and this will discourage its adoption and use.
I'm almost tempted to say that this is something they have addressed, or will address, as part of Cell, and that the same analysis will be used by IBM to sell Cell as a superior alternative to AltiVec (which IBM has never liked). But I've been wrong about Cell so many times now that I can only offer that speculation tentatively.
IBM discusses shortcomings of AltiVec. The link is to the second page of a performance comparison between Mot's and IBM's AltiVec implementations. The interesting stuff (for us) is the discussion of autovectorization right before the summary, and the discussion of the shortcomings in the summary.
The additions proposed are more minor than most of the AV2 rumors (i.e., there is no call for 4-way 64-bit SIMD, just a way to store 64-bit values), but they're additions to the ISA, and thus significant going forward.
None of this means that IBM will ship such a beast, and there are genuine concerns if they do—if Motorola decides not to adopt their improvements, then AltiVec has its first really serious fracture in terms of implementations, and this will discourage its adoption and use.
I'm almost tempted to say that this is something they have addressed, or will address, as part of Cell, and that the same analysis will be used by IBM to sell Cell as a superior alternative to AltiVec (which IBM has never liked). But I've been wrong about Cell so many times now that I can only offer that speculation tentatively.
Comments
Originally posted by Amorph
...courtesy of stingerman@Ars...
Amorph, the link does not work.
Originally posted by Amorph
I have, over the years, and recently, pooh-poohed any rumors about an "AltiVec 2," so I suppose it's only fitting that I post the first really firm evidence of such a thing (courtesy of stingerman@Ars) and publicly eat crow.
I'd take that bird out of your mouth.
The article in question:
IBM discusses shortcomings of AltiVec.
Is a comparison of different programming techniques as they apply to IBM's and Moto's chips. No mention is made of "Altivec 2," only of an IBM2 which references a double word read scheme in an algorithm.
The additions proposed are more minor than most of the AV2 rumors (i.e., there is no call for 4-way 64-bit SIMD, just a way to store 64-bit values), but they're additions to the ISA, and thus significant going forward.
Sorry, no additions being proposed here, the authors are just speculating on hardware improvements that would help improve the performance of this particular algoritm (TCP Checksums).
Originally posted by Amorph
I have, over the years, and recently, pooh-poohed any rumors about an "AltiVec 2," so I suppose it's only fitting that I post the first really firm evidence of such a thing (courtesy of stingerman@Ars) and publicly eat crow.
I'd hate to see you eat crow before better evidence than this comes in. Admittedly I just skimmed through the article but I only saw this as speculation on how to improve a programs performance by adding new instructions.
Now one could see this as preparing the masses for AltVec2 or one could see this a fanciful meanderings of people with too much time on their hands.
Since I'm in the camp that AltVec2 is need and can be implemented in a very positive manner, I do not actually find much support here that AltVec2 is actually on the way.
IBM discusses shortcomings of AltiVec. The link is to the second page of a performance comparison between Mot's and IBM's AltiVec implementations. The interesting stuff (for us) is the discussion of autovectorization right before the summary, and the discussion of the shortcomings in the summary.
It is the nature of computing systems and electronics in general that systems have short comings. Finding these shortcomings and addressing them is what allows us to move forward technology wise. Frankly it is good that people at IBM are looking at AltVec shortcomings, but I would not take that as an indication that this is a preannouncement of AltVec2 instructions. It could just as well be a priming mission for new processors or simply a study that goes no where.
What is interesting about AltVec is that there is a lot of potential there for expansion of the execution units or capability enhancements.
The additions proposed are more minor than most of the AV2 rumors (i.e., there is no call for 4-way 64-bit SIMD, just a way to store 64-bit values), but they're additions to the ISA, and thus significant going forward.
I did not see this as a positive indication that anything was abotu to happen just that the developers thought that a couple of minor new capabilities would have helped alot in their specific area of study. That is not how ever unusual, the same conclusion could come with respect to the FPU for certain codes.
None of this means that IBM will ship such a beast, and there are genuine concerns if they do—if Motorola decides not to adopt their improvements, then AltiVec has its first really serious fracture in terms of implementations, and this will discourage its adoption and use.
Actually IBM's and Freescales markets are so disimilar that sharing the technology should not be a problem. In fact I suspect that both companies understand the need for a common ISA. Besides I'm still really unsure about how much of AltVec Apple acutally owns.
I'm almost tempted to say that this is something they have addressed, or will address, as part of Cell, and that the same analysis will be used by IBM to sell Cell as a superior alternative to AltiVec (which IBM has never liked). But I've been wrong about Cell so many times now that I can only offer that speculation tentatively.
There are several things that are possible with Cell that may be easy to introduce because it is a new architecture. I would suspect though that the vector capability will be enhanced to a far greater degree than many suspect. Lets face it AltVec and the various other SIMD implementation on the various processors have been a fine learning ground to define what is really needed. So it should come as no surprise what so ever that Cell will have a robust vector processing capability.
For Cell to work at all it has to offer significant advantages over current hardware. Due to that very fact I suspect that Cell will introduce instruction units with significant enhancements. Here I expect to see vector processing handled as another core running in its own thread.
Or maybe not as I've been wrong myself at times. The reality is that Sony / IBM and whomever will run the risk of buring people out on the whole concept if they don't start to deliver information to people about Cell. Frankly MicroSofts approach with three PPC cores on a chip seems to make more sense and is certianly easier for people to swallow. Cell is running a big risk in my opinion with the secrecy, it takes time for people to digest something new so adopting something similar to existing technology is often the comfortable approach.
As AltVec2 well I believe enhancements are coming in some form. The primary reason is to keep performance moving forward and adding capability that is costly today. It will happen because the die realestate is there and the performance demand is there. To drive adoption though I suspect that the overhaul will be much more than a couple of instructions. There is just to much unexploited territory there.
Dave
Of the three things they list at the end of the article:
1) 64-bit integer support would make things somewhat more convenient for them, but they didn't qualify how much of an improvement this would make to their algorithm.
2) They did qualify how much of an improvement this one would net: none.
3) This one is an implementation improvement, not an instruction set change. It could show up in a future processor and run the existing software more optimally than the current hardware does. I'm all for that.
As for Cell...
Originally posted by Zapchud
It's because the Ars forum is having problems.
About a month or so ago Ars Technika made a big deal about switching over to Windows server 2003. Eating their own dog food so to speak. Well it would seem that the switch may be giving ars indegestion (or maybe even food poisoning) due to the switch to their favored OS.
Clicking on the Ars "forums" link now gives this message:
Hey, it worked !
The SSL/TLS-aware Apache webserver was
successfully installed on this website.
If you can see this page, then the people who own this website have just installed the Apache Web server software and the Apache Interface to OpenSSL (mod_ssl) successfully. They now have to add content to this directory and replace this placeholder page, or else point the server at their real content...
So have they ditched Windows 2003 and gone back to Apache?
Click the OS name to get uptime info e.g.
Uptime (and OS switchover) graph for www.arstechnica.com: http://uptime.netcraft.com/up/graph/...rstechnica.com