Hacker News Reader

Comment by theandrewbailey | Hacker News Reader

> The Power Mac G4, which features the PowerPC G4 processor with its remarkable Velocity Engine, runs professional applications like Adobe Photoshop over 50 percent faster than 800 MHz Pentium III-based PCs.

Is that any faster than modern versions of Photoshop today?

View on HN

Is that any faster than modern versions of Photoshop today?

I think you all may be missing the invisible sarcasm tag here. I am reading this more as a jab at Photoshop for not “feeling” faster on a contemporary multicore GPU-enhanced machine.

Which, honestly, in my distant memory, Photoshop doesn’t feel faster today. Oh, I know it objectively is much faster — you can rip through 40+ megapixel images with GPU-powered filters like it’s nothing. But whatever hideous custom interface kit Adobe uses make it feel perceptually pokey.

Like, I just opened the Libraries panel for the first time on this new computer, and there was a noticeable wait as it rendered the “rich toolip” thing they have. The default New Document interface has lurching slowness as well. The interface just always feels a teeeeny bit behind your actions.

Thank you for your response. Yes, I'm taking a jab at Photoshop's complexity, in the vein of 'what Intel gives, Microsoft takes away'. I carefully considered adding \s, but I'm genuinely curious to know if Photoshop feels faster or slower today (today's computers running today's Photoshop) versus 1999's computers running 1999's Photoshop. It seems about the same?

That Photoshop was probably CS2 IIRC. I'm fairly sure that software bloat has eaten all the speed gains from faster processors. I have an old 1.33 GHz Powerbook which runs 2004 Word as fast as my M1 macbook runs Office today. If I put in an SSD it might even be faster.

> If I put in an SSD it might even be faster.

I think most of the retro youtubers I've seen have done this mod along with PRam battery replacements that don't leak. They seem to use the m.2 SATA mode drives to 44pin like thus (not recommending, just showing an example) https://www.amazon.com/44pin-Converter-Adapter-Computer-Acce...

OpenBSD for macppc would run perfectly fine and fast enough on that.

Not for JS heavy sites, but Seamonkey with UBlock Origin Legacy would do a great job.

For youtube, Mplayer and yt-dlp would do the job. SMPlayer + "open url" dialog for graphical folks.

Do you think the g4 would have enough juice to do software decoding of h264 in real time? (slash is ffmpeg optimized enough for a relatively obscure platform like macppc? e.g. does it actually use altivec?)

IDK on FFMPEG, but for sure MPlayer had altivec support from the G4 days.

Also, pair a good video card with XV/XVMC support.

Also, for last drip of perfomance:

   mplayer -lavdopts skiploopfilter=all file.mkv

    mplayer -lavdopts skiploopfilter=nonrefs file.mkv

mplayer uses ffmpeg to decode h264.

MPlayer primarily uses libavcodec (the -lavd in your command line refers to it) for decoding, which is part of ffmpeg: https://ffmpeg.org/libavcodec.html

There was a lot of overlap in MPlayer and ffmpeg in the early days. Things like both projects sharing the same infrastructure, MPlayer developers automatically getting commit access to ffmpeg, ffmpeg sources having references to MPlayer, several top developers active in both, etc.

It's to the point that I think of ffmpeg as a spin-off of MPlayer, but perhaps that's not fair. Maybe it's more accurate to say that several prominent MPlayer developers (and infrastructure folks) did double-duty for years, then many drifted over to working on ffmpeg exclusively. I know that's true for several lead folks. I'd have to go through the ancient mailing list archives to sharpen my recollection of events. Perhaps somebody else who was also around at the time recalls a clearer perspective.

IDK but before the ffmpeg(1) tool everyone used mencoder (and transcode(1) ) to transcode media.

DVD ripping used transcode and/or mencoder.

ffmpeg has dedicated code for decoding h264 on ppc, as well as all the support code for rescaling and yuv->rgb conversion etc. It's probably not going to be able to decode super ultra duper high bitrate h264, but I would expect it to be able to decode 24fps 720p at standard bitrates without breaking a sweat, and it probably ought to be able to handle 30fps 1080p.

https://github.com/FFmpeg/FFmpeg/tree/master/libavcodec/ppc https://github.com/FFmpeg/FFmpeg/tree/master/libswscale/ppc

In 2001 I was using a G4 with Mac OS 9.2 for Photoshop while working at a studio; that was Photoshop version 7, which is pre-CS (which started with 8.0). My memory of the workflow at that time was that most system operations were snappy as hell. Sure, there was a bit of load time for very large files and some of the operations had a bit of lag but there really became a point around that time that the speed of work that you could do for most operations essentially matched the speed of the machine. Before that era, I remember going to use the cloning tool on a large, high-DPI image and getting a lag as you dragged the brush over a spot... waiting for it to catch up. The G4, especially when we upgraded one with more ram and OSX (which also was a huge change that happened to coincide with the G4) is when I remember machines getting to the point where I wasn't waiting on lag all the time when working.

I used both a 1Ghz iMac G4 and 2Ghz iMac G5 (ALS model) in the 2000s for a lot of Photoshop work and remember them performing similarly. Both were excellent machines for that particular use case and zipped through anything I threw at them in PS, especially the G5 which I put 2GB of RAM in.

The PS versions I used were chiefly 7.0 and CS1, with some CS2 mixed in towards the end of the G5’s lifespan. I miss those versions so much because they sat at nearly a perfect nexus of features, responsiveness, and resource consumption. Such a stark contrast to PS CC.

> Is that any faster than modern versions of Photoshop today?

I seriously doubt that. Consider that Velocity Engine is another marketing term for AltiVec, PowerPC's SIMD instruction set. The Pentium III only supported SSE, which was a lot more basic in term of capabilities.

But SSE was extended a lot by Intel with the succeeding processors (SSE2, SSE3, SSSE3, SSE4 (SSE4.1, SSE 4.2)), and supplemented two times by a more capable SIMD instruction set (AVX, AVX-512). By the way: SSE was intended to replace the older MMX SIMD instruction set (and to replace the x87 FPU by a modern floating point instruction set). So, if we consider AVX-512 to be the "sensible" instruction set for SIMD on x86, Intel needed four attempts to get it right. ;-)

So, I really doubt that Velocity Engine/AltiVec can compete with the modern x86 SIMD units. But it is very easy to admit that AltiVec's SIMD instruction set design is much more elegant and orthogonal than modern x86 SIMD (say, AVX or AVX-512).

Only certain operations were sped up by the vector extensions. People on PC forums would post their "jobsmarks" showing they beat Apple, the G4 was sorta a disaster. The replies are ranting about general software bloat, but I'd bet the image processing parts of photoshop are still highly optimized.

Adobe has made more things multi-threaded over the years so probably not. ARM has SVE too which I assume is similar to the 'velocity engine'

Velocity Engine was a marketing name for Altivec (which was also a marketing name, just IBM's instead of Apple's). Altivec was roughly comparable to Arm's NEON (32 128-bit registers, packed 32-bit float operations making the largest part of the ISA extension), but with a few key differences. Altivec had a much richer set of basic integer operations than neon (VPERM, you were my best friend), but NEON supported packed 64-bit double-precision floats. In general as a developer Altivec was much more fun to work with, and I'd expect that for Photoshop it was probably the more powerful vector ISA as well.

SVE is a successor to NEON that, besides supporting flexible vector sizes, reflects another couple decades of learnings about vector ISA design and a few orders of magnitude more available transistors.

Altivec did magic with MPlayer. 720p video on a G4? Totally doable.

Altivec was just fun to work in. Much like writing PPC assembly in general, it felt like a civilized toolbox with a good set of hand tools -- you have your socket wrench of each size (byte, short, int), and you always know what to reach for -- but then it came with just a couple power tools -- vperm and vsel were basically your electric drill and impact wrench, and every once in a while you'd realize that instead of doing a perfectly good job banging out the result with your hand tools you could just finish the damn thing right now with the power tools. And when you could, you ended up code that was shorter, simpler, faster, and easier to write. So rewarding.

GameCube and Wii developers knew lots of tricks for that, sure.

The GameCube/Wii vector ISA instruction was not Altivec, and not very similar. It used 64-bit vectors (packed as two 32 bit floats usually), so half the size of Altivec, NEON, and most of its contemporaries. These packed vector instructions shared the register file with the floating point unit (that is, an FP register could contain either a 64-bit float acted on by a normal floating point instruction or two 32-bit floats acted on by a vector instruction), rather than having a dedicated separate register file like Altivec. And most of the fun instructions had no equivalent.

Altivec was Motorola's trademark. IBM worked on it, too, and called it VMX, but didn't make chips using it until the 970/G5.

Often lost in the noise is that Apple was the most visible, but not the only customer of Motorola's chips (witness all the variants that never made it into a Mac). Of course, Jobs liked to act as if others didn't exist and Motorola was Apple's own CPU department. I wish someone with knowledge would describe how or why IBM decided it was a good idea to sell silicon to him. It did prepare them a bit for the Cell partnership with Sony and Toshiba, but there's probably more to the story than that.

Reply on news.ycombinator.com