OT eye on the future cpus for saw

[jmh]

I read that qualcomm has an arm processor soc, and that AMD & Nvidia will too, that will be aimed at windows laptops. If these cpus show good single thread stats on a benchmarker, the test would optimized when compiled for that platform. Since saw is '86 based, it is possible (or probable) that performance gains on those architectures may not carry to saw.

Anyway, a thought to have in mind when doing future hardware upgrades...

[mr_es335]

jmh,

You stated, "...a thought to have in mind when doing future hardware upgrades..." "Nah!"

I do believe that there is a simple principle that is often missed or forgetting here on this Forum...if you would be so kind as to humour me for a moment, "What did the software developer have in mind when that developer first developed that software?"
* With the original iterations of both SAC and SAW...I do believe that the answer to that query would be, "Windows XP, 32-bit". [Philip...please chime-in here!]

With this in mind, I have obtained a number of Intel boards [DH67BL], with an intel i5, 2nd Gen [2500] processor, and 16GBs of RAM - some in almost in new condition, as backups, if-and-when my existing motherboard dies.

I have obtained excellent results from this board, with XP Pro, WIN7 PRO and WIN10 LTSC.
* My latest tests have WIN10 booting in 8 seconds!
* My latest move to WIN10 is only the result of having to upgrade my guitar ampsim software - which requires WIN10...otherwise I would have stayed with WIN7.

In short, for me anyhow, "Avoid 'GAS' and get to work!"

[jmh]

"What did the software developer have in mind when that developer first developed that software?"
* With the original iterations of both SAC and SAW...I do believe that the answer to that query would be, "Windows XP, 32-bit". [Philip...please chime-in here!]

This is exactly the point. Bob had hand optimized x86 instructions in mind. Windows is just incidental - although I believe there is a good deal of Microsoft dll utilization for dialogs and graphics - which would explain why there was never any moves toward being multi-platform. Also saw was solid on millennium edition, something no other programmer had ever achieved*.


* this sentence is a joke - however it still may be true.

[jmh]

Yea when you figure out how to strip away all the unneeded junk, you can get things to move along pretty well. 8 seconds, nice. I had 11 in that neighborhood (including a noticeable POST) - unfortunately the startup for the Presonus series iii driver is not reliable so I had to add a 30 second delay to the bios so it would work (mostly) consistent if the mixer finishes booting before windows. There's always something (presonus should be embarrassed to have fluky driver operation on an otherwise great system).

Coincidentally, I just put new firmware on the mixer and the latest driver in windows - but have yet to try firing up the rig without the delay.

[jmh]

Actually I didn't spell out why I brought up this topic in the first place. I think arm processors use reduced instructions, so if legacy code is running, the target instruction set may be implemented via emulation rather than as native instructions designed into silicon chips. Various non-native instructions might take many times more cpu cycles to achieve than they would on the real hardware that supports them. In our case, this would undo Bob's hard work to make saw quick. There is the possibility that the 'simpler' RISC environment enables a chip to run faster and gains could exceed losses. Basically I was saying we should not have expectations for non-x86 chips for saw until one of us has taken the time to figure out if they are a match.

[cgrafx]

SAC and SAW Studio would have to be fully recompiled for any non-x86 architecture.

Its is not even remotely reasonable to think that Microsoft will build an interpretor for Arm-based windows platforms the way Apple did, so I wouldn't hold my breath that there will be any option short of a re-compile/build from Bob.

As far as performance goes, for most use-cases, almost any basic modern x86 system is more than capable of running SAC and/or Saw Studio with plenty of headroom.

There really isn't any compelling reason to worry about ARM architecture builds at this point in time, as it will be years before windows ARM systems are going to be mainstream enough to be useful.

Its not enough to just have the OS running, there has to be I/O and driver support and that is simply going to take time.

[jmh]

SAC and SAW Studio would have to be fully recompiled for any non-x86 architecture.

Its is not even remotely reasonable to think that Microsoft will build an interpretor for Arm-based windows platforms the way Apple did, so I wouldn't hold my breath that there will be any option short of a re-compile/build from Bob.

As far as performance goes, for most use-cases, almost any basic modern x86 system is more than capable of running SAC and/or Saw Studio with plenty of headroom.

There really isn't any compelling reason to worry about ARM architecture builds at this point in time, as it will be years before windows ARM systems are going to be mainstream enough to be useful.

Its not enough to just have the OS running, there has to be I/O and driver support and that is simply going to take time.

Time? This already exists. Windows runs on arm on raspberry-pi - but Saw will never be recompiled for non x86 - or at least not with the custom hand optimized assembly code.

[cgrafx]

Time? This already exists. Windows runs on arm on raspberry-pi - but Saw will never be recompiled for non x86 - or at least not with the custom hand optimized assembly code.

that is a third party hack, not a Microsoft port. Certainly fun to play with, but absolutely not ready for a production deployment.

I have no doubt Microsoft will have some windows variant available for arm in the future, its just not there yet, and there will likely still be a delay before companies like RME, Motu, etc, will have interfaces available for deployment.