Enhancements to the SAS Programming Run-Time Servers with SAS Viya Stable 2025.02
Starting with SAS Viya stable release 2025.02, it is now possible to run in-memory and many more multi-threaded procedures in SAS programming run-time servers. This builds on the technology developed initially for use with CAS Servers and multi-language architecture (MLA) found within SAS Viya Workbench. This can reduce the dependency for SAS Viya users to submit data processing within a CAS Server. SAS programming run-time servers can now run almost any code developed in SAS programming languages or Python. And there is now a greater opportunity to leverage the power of GPU processing for analytical procedures.
How has this come about? Well, with the introduction of the multi-language architecture (MLA) released with SAS Viya Workbench, the use of CAS actions without requiring a deployed CAS server has now become possible. These innovative features and capabilities developed initially for SAS Viya Workbench, have now been added as enhancements to the SAS programming run-time servers, including SAS compute servers, SAS/CONNECT servers, and SAS batch servers. In practice this now allows both data scientists and programmers to easily switch between SAS Viya and SAS Viya Workbench environments should they need to do so. This is because there is such a large degree of code compatibility between the environments.
In addition Python programs developed with SAS Viya Workbench using the SAS proprietary sasviya.ml Python package were not available in a SAS Viya environment. Until now, the sasviya.ml package was only available with SAS Viya Workbench. From February 2025, Python packages such as sasviya.ml will be accessible in SAS Viya environments. Examples of using the sasviya.ml package can be found in the Python section of the SAS Viya Workbench examples on GitHub.
Runtime diagrams
Let's use a few diagrams to understand what has changed, or, better, what are the new capabilities that have been added. We will use a SAS compute server to illustrate the concepts, but the same applies to SAS/CONNECT and batch servers. Remember when looking at the diagrams, it is important to note that for each user there will be a corresponding SAS programming run-time server pod. So for 50 users, there will be 50 pods. Each CAS Server can serve multiple users, so for CAS the number of pods does not increase with the number of users unless there are scaling options enabled/triggered.
Before SAS Viya 2025.02, code running in a compute server has essentially two execution paths. Traditional SAS code, i.e. the same that would run in a SAS 9 environment, runs in-process. This means that it uses the memory and CPU of the hosting SAS process.
To exploit the additional computing power provided by CAS servers, the user/programmer would code in the CAS language or use CAS procedures. That code is only interpreted by SAS, then the execution is delegated to the CAS server. That’s the only way to execute the most advanced analytical procedures.
In the past years, following a continuous delivery paradigm, we incrementally released new CAS-enabled procedures, which present a “SAS-like” syntax that lets you code CAS’ most advanced analytical procedures without having to learn the CAS language. These procedures can still be interpreted by SAS and then delegated to the CAS server, which will in turn execute the same CAS actions as if it was called by the CAS language.
Starting with SAS Viya 2025.02, these options are still available, plus we added a new execution path. The same CAS actions, that are available in the CAS server, are now embedded and executed in the SAS compute server process. These CAS-enabled procedures can now be parsed and executed without leaving the SAS process. We will discuss below the benefits and the additional considerations that this capability brings to the SAS Viya platform.
How can SAS know if CAS-enabled PROCs should be run in-process or delegated to CAS? The answer is in the data. If the input data is in a SAS library, then the CAS action will run in-process. If the input data is in a caslib hosted by a CAS session, then the CAS action will be delegated to the CAS server.
Finally, let’s focus on the SAS process and the new CAS actions executed in-process. This capability is referred to as “multi-language architecture”, or MLA, because the same CAS actions can be called by Python code, via the sasviya.ml package. As mentioned previously, this package was initially only available with SAS Viya Workbench, and it’s now included with all the SAS Viya offerings.
The Python environment is optionally configured in the SAS programming run-time servers using the standard process described the SAS Viya Platform: Integration with External Languages guide.
Deployment considerations
Updating SAS Viya to the 2025.02 stable release or later automatically brings all the binaries and components that provide these enhancements. You do not have to install any other software, just update to the latest version as usual.
The new capabilities are automatically included in all SAS Viya offerings with no additional fees, but they perform a license check to verify that they are executing in a licensed environment. Every SAS Viya license created and applied until the 2025.01 stable release does not include the code that enables them, while every license created and applied starting with the 2025.02 release does. As part of your regular update to 2025.02 or later, you will automatically get a new license that includes these new components, and it will be be applied by the update process.
There is one additional step that you have to perform to fully enable these capabilities, both for new deployments and for updates.
To support the multi-language Python library for SAS Viya Enterprise (sasviya.ml), you must enable the installation of the required Python packages. This is an additional step included in the Configure Python Integration Using SAS Configurator for Open Source page of the SAS Viya Platform: Integration with External Languages guide. It’s very easy; while following the instructions from that page, simply set to “true” the value of a new setting found in the $deploy/site-config/sas-pyconfig/change-configuration.yaml file, used to enable the SAS Configurator for Open Source.
- op: replace
path: /data/default_py.pip_local_packages
value: "true"
Architecture considerations
The SAS Viya architecture does not change, you can keep the same deployment topologies. Currently, all of the existing components are still required, including the requirement to deploy at least one CAS server. Indeed as of February 2025, a CAS Server is still the required analytics engine for use with SAS Visual Analytics. There will be other clients, such as Model Studio, that will require data be loaded into the CAS Server. Please refer to SAS Viya documentation for more information.
It’s important to understand that, when you run CAS actions inside a SAS programming run-time (Compute) server, all the data is loaded in memory and the code executes in a single pod. For this reason, you can only benefit from vertical scalability, by allocating additional CPU cores or more Memory/RAM to the individual compute server pods. One approach to providing SAS programming run-time (Compute) server pods with varying numbers of CPU and allocated Memory/RAM is to provide users with different Compute server contexts.
In the use cases where the data being analyzed is very large, or there are a large number of users accessing the same data, a larger number of CPUs and RAM may be required. In those scenarios, you can always switch to using a distributed CAS MPP server, with its horizontal scalability only limited by the available hardware that you can throw at it. Instructing SAS to execute the code in-process or offload it to a central CAS server is as easy as declaring a SAS library as the input data, versus using a caslib associated with a CAS session.
Running CAS actions inside SAS programming run-time (Compute) servers, might require more resources than those provided by a default configuration. Internal performance testing has demonstrated that SAS servers executing CAS actions can be as fast as SMP CAS servers running the same code, provided they are allocated the same resources, and properly configured to use them.
At the same time, not everyone in your enterprise will probably need beefy, expensive server instances. A good architecture design might call for multiple compute node pools and different Compute Server contexts, with different resource capabilities – and different costs. Remember that with the features of SAS Workload Orchestrator, it is possible to implement different Compute Server contexts using queues. This will also help keeping cost in track if you want to provision GPUs for specific use cases. Which ones? Keep reading below!
A final architectural note. You might have noticed that we wrote, above: “when you run CAS actions inside a SAS programming run-time (Compute) server, all the data is loaded in memory”. This behavior is inherited from CAS, and, just like regular CAS servers, SAS uses temporary disk space to back its process memory. This means that proper storage design might be required, but we’ll leave this consideration for another time.
Additional benefits
With the ability to run CAS based process on SAS programming run-time (Compute) servers there are new possibilities to leverage GPUs. Prior to February 2025, PROC IML was the only procedure that could leverage GPUs when executing in a SAS programming run-time server. To benefit from the multiple analytical procedures that can run faster on a GPU, programmers had to run code on a CAS server (For example, see https://go.documentation.sas.com/doc/en/pgmsascdc/default/casdlpg/p0hj75sw11grh2n1fg225n1uj61d.htm). Starting with the SAS Viya 2025.02 stable release, all these GPU-enabled procedures are available and can be executed in the SAS programming run-time server. Obviously, training a deep neural network on a very large data set is a time-consuming task, even with the advantages of GPU acceleration. Distributing the workload across multiple nodes in a cluster environment effectively reduces the runtime over a single node setup. That’s an example where you can still leverage the horizontal scalability provided by CAS MPP servers.
The need to configure a personal CAS server is now limited to a few specific cases. A personal CAS server, which is an ephemeral CAS server, is created on demand for a single user. For development purposes data scientists want the ability to work with advanced analytic procedures that, as we have seen, until now were only available in SAS Workbench or, in SAS Viya enterprise environments, through a CAS server. Imagine a few data scientists submitting resource-intensive tasks to central CAS server shared with the rest of the enterprise. They could negatively affect all of the other clients of the shared server. Until now, the only solution was to configure personal CAS servers, but this required additional considerations for proper design and setup. Starting with the SAS Viya 2025.02 stable release, data scientists can simply submit their advanced analytics to a SAS programming run-time server running on a dedicated, scalable node pool, and no one else is impacted.
Closing comments
The enhancements to the SAS programming run-time (Compute) servers in the February 2025.02 release of SAS Viya are hugely significant. They will provide customer organizations with the potential to run their SAS Viya workloads even quicker and at the same time potentially reduce the total cost of ownership. And from an architecture, administration and deployment perspective the new enhancements do not increase the complexity in most scenarios. So for customer organizations who have both SAS and Python programmers looking to speed up the completion of their workloads, SAS Viya 2025.02 will be a great benefit to them.
Find more articles from SAS Global Enablement and Learning here.
