Category Archives: Parallel Processing

High Performance Workstations for BI

There’s one thing I really enjoy and that’s powerful workstations for performing analytics. It’s fun to play around with and can be insightful to speculate on the design and then build a custom higher-end workstation for running BI applications like WPS and R.

ARS Builds

Every quarter, ARS Technica goes through an exercise where they build three PC’s mainly to assess gaming performance and then do a price vs. performance comparison. There’s a trend that you will soon see after reading a few of these quarterly builds and that is, the graphics card plays a major role in their performance assessment. The CPU, number of cores and fixed storage tend to be minimal when comparing the machines.

This if course will be in contrast to what we want to do for our performance benchmarks. We are looking at a holistic approach of CPU throughput, DISK I/O and graphics for getting the most for the dollar on a workstation build. But ARS does have a lot to recommend when it comes to benchmarking and I think it’s worthwhile including some of their ideas.

What Constitutes a High End Analytics Workstation?

This is an interesting question and one that I will throw out for debate. It’s so easy to get caught up in spending thousands of dollars, if not ten thousand dollars (see the next section) for a work station. One thing that even the casual observer will soon notice is that being on the bleeding edge is a very expensive proposition. It’s an old adage that you are only as good as your tools. There’s also the adage that it’s a poor craftsman that blames his tools. In the BI world, especially when speed means success, it’s important to have good tools.

As a basis for what constitutes a high end workstation, I will offer the following as a point of entry.

  • At least 4 Logical CPU’s.
  • At least 8GB of RAM, preferably 16GB to 32GB.
  • Multiple hard drives for OS, temporary workspace and permanent data set storage.
  • A graphics card that can be used for more than displaying graphics, i.e. parallel computing.
  • A large display – 24” capable of at least 1920×1080.

As a mid-tier solution, I would think that a workstation comprised of the following components would be ideal.

  • At least 8 Logical CPU’s.
  • A minimum of 16GB of RAM.
  • Multiple hard drives for OS, temporary workspace and permanent data set storage with emphasis on RAID storage solutions and SSD Caching.
  • A graphics card that can be used for more than displaying graphics, i.e. parallel computing.
  • A large display – 24” capable of at least 1920×1080.

As a high end solution, I would think that a workstation built with the following hardware would be close to ultimate for many (if not most) analysts.

  • Eight to 16 Logical CPU’s – Xeon Class (or possible step down to an Intel I7).
  • A minimum of 32GB of RAM and up to 64GB.
  • Multiple hard drives for OS, temporary workspace and permanent data set storage with emphasis on RAID storage solutions and SSD Caching.
  • A graphics card that can be used for more than displaying graphics, i.e. parallel computing.
  • Multiple 24” displays capable of at least 1920×1200 each.

I do have a bias towards hardware that is upgradeable. All-in-one solutions tend to be one shot deals and thus expensive. I like upgradability for graphics cards, memory, hard drives and even CPU’s. Expandability can save you thousands of dollars over a period of a few years.

The New Mac Pro – a Game Changer?

The new Mac Pro is pretty radical from a number of perspectives. It’s obviously built for video editing but its small size is radical in my opinion. As a Business Analytics computer it offers some intriguing prospects. You have multiple cores, lots of RAM, high end graphics but limited internal storage. That’s the main criticism that I have about the new Mac Pro. The base machine comes with 256GB of storage and that’s not much for handling large data sets. You are forced to go to external storage solutions to be able to process large data sets. Although I’ve not priced out the cost of adding external storage, I’m sure it’s not inexpensive.


This is a tough one for me because so many organizations have such an array of hardware and some benchmarks are going to require hardware that has specific capabilities. For example, Graphics Cards that are CUDA enabled to do parallel processing in R. Or the fact that we use the Bridge to R for invoking R code and the Bridge to R only runs on WPS (and not SAS).

I did write a benchmark a while ago that I like a lot. It provides information on the hardware platform (i.e. amount of memory and the number of LCPU’s available) and just runs the basic suite of PROCS that I know is available in both WPS and SAS. Moving to more statistically oriented PROC’s such as Logistic and GLM may be difficult because SAS license holders may not have the statistical libraries necessary to run the tests. That’s a major drawback to licensing the SAS System. You are nickel and dimed to death all the time. The alternative to this is to have a Workstation benchmark that is specific to WPS.

Perhaps the benchmark can be written where it tests if certain PROCS and Libraries are available and also determine if the hardware required is present (such as CUDA processors) to run that specific benchmark. Really, the idea is to determine the performance of the specific software for a specific set of hardware and not a comparison between R, WPS and SAS.

Price and Performance Metrics

One aspect of ARS that I really like is when they do their benchmarks, they calculate out the cost comparison for each build. They often base this on hardware pricing at the time of the benchmark. What they don’t do is price in the cost of the software for such things as video editing, etc… I think it’s important to show the cost with both hardware and software as a performance metric benchmark.

Moving Forward

I’m going to take some time and modify the WPS Workstation Benchmark Program that I wrote so that it doesn’t spew out so much unnecessary output into the listing window. I would like it to just show the output from the benchmark report. I think it would also be prudent to see if some R code could be included in the benchmark and compare and contrast the performance if there are some CUDA cores available for assisting in the computations.

About the author: Phil Rack is President of MineQuest Business Analytics, LLC located in Grand Rapids, Michigan. Phil has been a SAS language developer for more than 25 years. MineQuest provides WPS and SAS consulting and contract programming services and is a authorized reseller of WPS in North America.

Another View of R and Big Data

I was reading a blog entry the other day that just blew me away. Librestats has a blog entry entitled, “R at 12,000 Cores” and it is a very good (and fun) read. It’s amazing what can be done by the open source advocates and this article is a great example of that.

After reading the article, I can’t help but think about the relationship between extremely large data, server size (both CPU’s and RAM) and how fast data is growing. There has to be a way to crunch through the amount of data that is piling up and this article addresses that issue.

I believe you will begin seeing vendors embrace R more openly, mainly because they have to embrace it. There’s not any companies that can develop code at the break neck pace that the R community is putting out packages. It’s truly amazing and cost effective to model data in the way that the above article describes the state-of-the-art.

Even small companies can make use of multiple servers with dozen of cores and lots of RAM rather inexpensively. Using Linux and R on a set of servers, an organization can have a hundred cores at their disposal for crunching data and not paying very much in licensing fees.

I have been giving some thought to making the Bridge to R run in parallel on a single server as well as across a set of servers using WPS and pdbR or Rmpi. This way, WPS would handle the management between the servers and the data transparently and provide for number crunching at very low cost. God knows we have a few extra multiple core servers laying around here so it may be an interesting adventure to give this a spin!

My first thought and intention is to make the code backward compatible. Perhaps just add a macro that can be called that contains the information needed to implement running R across cores and on a grid. It could be something as simple as:

%Rconfig(RconfigFile=xyz, RunInParallel=True||False);

The remaining statements in the Bridge to R would continue as they are and the R code would be pushed to the servers based on the information in the RconfigFile. WPS would still collect the output from these jobs and route the appropriate information to the log and listing window as well as the graphics to the graphics viewing window (wrapped in HTML) for users to view their output.


Services for WPS Conversions and Evaluations

It’s been a while since we’ve reviewed and re-jiggered the services that we offer and the ones we do offer need a bit of a makeover. Although our existing services are still pretty pertinent, we are looking at expanding and rounding out our consulting services in the area of SAS to WPS conversions. In the next few weeks we’ll be modifying our website to reflect these changes as well as creating some marketing brochures that can be downloaded and shared.

Many organizations are looking to significantly reduce software cost over the next two to three years. They don’t want to necessarily change their current architecture and most want to continue using existing source code whenever and wherever possible. Based on those premises, we’ll soon be putting together a services portfolio that encompasses the following practices.

Work with IT or an organizations Analytics Departments in providing a WPS Proof of Concept.

  1. Evaluate Price/Performance
  2. Define the requirements for an analytical and/or reporting replacement.

Assist in the evaluation of WPS Software as a replacement to existing SAS products.

Perform detailed Code Evaluation on existing SAS user and production SAS code libraries to evaluate compatibility with WPS and provide or recommend workarounds as necessary.

Recommend hardware and specific configurations for a WPS Server Installation.

Provide SMP libraries for Symmetrical Multi-Processor Hardware.

Install and test The Bridge to R.

Provide guidance to companies who are Data Service Providers on how best to reduce their exposure to SAS DSP fees.

Provide Consulting to departments and users who are focused on particular projects, i.e.

  1. For re-architecting their systems.
  2. For jump start/quick start scenarios.

Although these last two may seem a little “out there” for many people, you would be surprised to find out how common it is that a company acquires another organization and inherits a system that requires immediate attention in terms of licensing, cost reduction or consulting assistance to move the system to a new platform. It’s also not a rare situation where a company needs to immediately move their source code off of SAS due to DSP issues, escalating server costs or license problems. In these situations, MineQuest and World Programming can be of immense help.

About the author: Phil Rack is President of MineQuest, LLC. and has been a SAS language developer for more than 25 years. MineQuest provides WPS and SAS consulting and contract programming services and a reseller of WPS in North America.

Looking Down the Road

We’ve had the Bridge to R out for about a week now and so far, it’s been very positive on the feedback. The Bridge is pretty stable and I think fairly easy to use after you setup R and install the Bridge itself.

Which brings us to what we may want to include in the next release. What we’re thinking about is including MPExec, and a nifty little macro called WPS2XML which allows you to create an XML file as well as generate a schema (DTD or XSD) from your WPS data set. The code for both utilities is already written and just requires testing in a more stressful environment.

So, what is MPExec? It’s a very robust utility that we wrote for WPS customers last year. MPExec stands for Multi-Processor Execution and it allows the WPS user to thread their programs so that they can run multiple parts of the program at the same time. On a multi-core desktop or server, one can dramatically reduce their programs execution time — depending on how well the program can be threaded.

Most programmers (and SAS programmers especially) think in a top down fashion when designing their programs. For example, you may have multiple steps to extract and clean data from a database, another set of steps that access data in a transport file that was created on the mainframe that also needs cleaned and sorted, and finally, some historical data that is sitting in another database on another server.

None of these three steps outlined above have anything in common (i.e. data sharing) in the sense that they have to run sequentially. Why not run these all at the same time on your multi-core desktop or server and save time? That’s exactly what MPExec allows you to do.

I’m interested in hearing what other users may have interest in when it comes to utilities to enhance and expand their use of WPS. Currently, the Bridge to R and the accompanying utilities are only available on Windows platforms. Is there a need or interest to have them also execute on Linux/Unix/Solaris? Of course, we’re always interested in hearing ideas about how we can expand our utilities to include R in a more seamless fashion as well.

About the author: Phil Rack is President of MineQuest, LLC. and has been a SAS language developer for more than 25 years. MineQuest provides WPS and SAS consulting and contract programming services and a reseller of WPS in North America.

Update on The Bridge to R v2.3

Over the last few days as time has allowed, we’ve been adding some features to the Bridge to R for WPS Users. We are also going to add some additional error detection for an upcoming release.

Probably the biggest effort has been on ispeeding up the process of passing data off to the R system. By using SAS Transport files instead of using CSV files, the time for R to read in the data is dramatically decreased. This really helps when multitasking and when running multiple R threads from within WPS.

The down side to using SAS transport files is that data set names and variables are limited to eight characters. The positive aspect is that precision between systems is preserved.

Previous versions of the Bridge to R required the use of an external DLL to execute some system processes such as checking for the existence of files and if a file was already in use. Version 2.3 of the bridge will not require the DLL and will do all the housekeeping internally. This also helps decrease overall execution speed. The other positive aspect of not requiring a DLL is that the Bridge to R is now portable between operating systems.

We’re also adding some additional error checking. It’s really difficult to determine all the possible things a user can do to cause the system to malfunction. But as we become aware of some of issues, we are trying to add code to detect that these conditions are out of bound and warn the user.

Currently, the Bridge to R can execute as many as 256 threads. This limitation will stay for the next release but more than likely that will have to be increased for any releases past V2.3. We’re now seeing Intel servers that with HyperThreading, have 96 threads available. IBM has announced new Power7 processors that as a system will have as many as 1024 threads.

About the author: Phil Rack is President of MineQuest, LLC. and has been a SAS language developer for more than 25 years. MineQuest provides WPS and SAS consulting and contract programming services and a reseller of WPS in North America.

Technorati Tags: ,,
LiveJournal Tags: ,,

Speeding up the Bridge to R for WPS Users

I’ve been considering rewriting parts of the Bridge to R for WPS Users in hopes of improving the usability of the software. Usually when I write code, I hope to gain functionality as well as improve processing speed and this does both… up to a point.

The aspect that bothers me most about the Bridge to R is that I have to write the WPS data to a CSV file (Comma separated Values) to be read in to a dataframe by R. This is often the slowest part of the process for many routines. If we had an ODBC driver, this would be a moot subject but I have to work with what I have. I also want to keep this compatible with SAS in terms of a code base so that limits me as well. Why? Because SAS is crippled and cannot read AND write a SAS dataset via ODBC.

The answer to some of these problems lies in the use of SAS xport files. R can read and write a transport file directly. WPS can read these files as well. Doing some tests yesterday, I noticed up to a 5x improvement in writing data using a transport file than when writing a CSV file. In my mind, that’s a huge improvement in speed.

Here’s a little table that shows the time differences between reading and writing a transport file versus reading and writing a CSV file. Note that all times are in seconds.


CSV Write

Xport Write

CSV Read

Xport Read





















However, a limiting factor of using a transport file is that the user is restricted to eight character variable names. I know we’ve all lived with this restriction before, when we used SAS V5 or V6 software so it may not be as restrictive as I think, but it would be nice to be able to transparently pass WPS or SAS variable names to R and to read them back in too.

About the author: Phil Rack is President of MineQuest, LLC. and has been a SAS language developer for more than 25 years. MineQuest provides WPS and SAS consulting and contract programming services and a reseller of WPS in North America.

Technorati Tags: ,,,

Multi-Processing WPS and SAS

In an article appearing on the Computerworld website, "Desktop multi-processing: Not so fast" the author, Lamont Wood, discusses some issues surrounding desktop applications and the ability to use all the cores and Hyper-Threads found on most current and modern desktop CPU’s. It’s an interesting read and it discusses problems that are found and being worked on for the typical desktop users. But WPS and SAS programmers are not typical users (at least in my opinion) and I think the type of work and processing they tend to do can often be threaded, especially when it comes to moving systems into production.

So how does Wood’s assertions affect WPS and SAS programmers? Developers who use the SAS language tend to fall into two camps. There are those who do a lot of ETL, reporting and database work, and then there are those who live in the statistics world. Both camps can make use of parallel processing and decrease execution and decrease total run time speed. In my world, I’m after decreasing total run-time speed and not so much concerned with CPU time.

So exactly how does a WPS or SAS developer run code that is parallelized? A SAS user has a few options and it varies depending on what products the user has licensed. For example, some SAS/Stat PROCS implement parallel processing, as does some BASE. Here’s a list I found on the SAS support website that makes use of SMP (symmetrical multi-processing) hardware. If you are a SAS user and have SAS/Connect, you can use that expensive product to run portions of your code in parallel to decrease your execution time.

If you are a WPS developer, you can use MPExec (Multi-Processor Execute) to run portions of your WPS code simultaneously and recombine log files, list files and datasets that were spawn from each thread. MPExec is very easy to use and I won’t go into it again other than to say you only have to learn three new keywords to implement it in your code.

At one level, MPExec is similar to SAS/Connect in that you can spawn multiple WPS Sessions where each session runs a thread. You, as the developer are responsible for eye-balling your WPS code to decide what sections of code will run in an individual thread. At another level, MPExec doesn’t have the baggage or the expense that SAS/Connect has going for it so it’s easier to use and justify.

Running MPExec or any other methodology that allows for multi-processing of your SAS and WPS programs often boils down to just two factors. The first, if you have sufficient cores to execute the threads that you want to execute, and two, if you have sufficient I/O to read and write the data sets for all the threads you are executing. I find that the I/O is typically what hinders WPS and SAS multi-threaded programs the most. But, if you have sufficient hardware, you can get some awesome gains out of your tried and true production code using MPExec.

And the best part of MPExec? MPExec is free if you license WPS for the Windows desktop or Windows Server from MineQuest.

About the author: Phil Rack is President of MineQuest, LLC. and has been a SAS language developer for more than 25 years. MineQuest provides WPS and SAS consulting and contract programming services and a reseller of WPS in North America.

Batch Schedulers for WPS

I’ve been thinking about the last blog post on running WPS in batch mode and it occurred to me that it might be a nice thing to have a batch scheduler that is tuned to running WPS in a client/server environment. Of course, there are batch schedulers out there that are commercial and tend to be pricey. You can get a list of these products by checking out:

I’m particularly interested in products that are either open source or are very inexpensive. From a quick glance, that leaves Sun’s Grid Engine, Open Source – Job Scheduler, Torque Resource Manager and GnuBatch. After looking over the four choices, I think the Open Source – Job Scheduler is the most applicable scheduler. It supports all the platforms that WPS executes on (Windows 2000/2003/XP/Vista, and in the future Linux, Sparc Solaris and Solaris x86, and AIX) with the exception of z/OS. The scheduler also has a web interface as well as email capability. The email capability would be nice so that the system can notify you of errors in a job.

One of the features of the Open Source Job Scheduler that I like is that it can run jobs in parallel and can handle chains and dependencies. The batch language is XML so it would be easy to change and it also has a GUI. About the only thing it doesn’t have is the ability to submit code directly to the server for immediate execution by use of drag-n-drop. It does have the concept of hot folders so that maybe something that can be used in conjunction with a little programming.

One other factor of note is that you can purchase support from SOS GmbH Software that includes a ramp-up service.

So I am curious what others are using for batch scheduling in production systems now days. Is the concept of scheduling for end users something that is foreign or just so uncommon that it’s rarely considered?

About the author: Phil Rack is President of MineQuest, LLC. and has been a SAS language developer for more than 25 years. MineQuest provides WPS and SAS consulting and contract programming services and a reseller of WPS in North America.


SOS GmbH Software:

Sun Grid Engine:

Torque Resource Manager:


World Programming Company:

MPExec Documentation Preview

We have the first draft of the documentation for MPExec. MPExec is a software add-in that allows for multi-threading WPS applications. I’ll place the document out on the MineQuest website for anyone interested in taking a look at it. Be forewarned, it is a first draft so expect some grammar and spelling issues.

The documentation is pretty short, only five pages long but you can easily read and understand what is required to run MPExec. Adding threading to a WPS program using MPExec is easy to do. Simply add a few statements to existing code segments that are good candidates for concurrent processing and you can dramatically reduce your applications execution time.

Right now, we are planning on including it as part of the MineQuest MacroLib. You can get the MacroLib included for free if you choose to license WPS (either Windows Desktops or Windows Servers) from MineQuest directly. The MacroLib includes some other useful applications such as XMLRead and XMLWrite, and the Bridge to R for WPS. We also plan on supporting MPExec on the Unix/Linux platforms in the future and we’ll announce that availability when we are thoroughly done testing.

If you’ve licensed WPS from WPC directly or some other reseller, we can offer an annual license for the MacroLib so you have access to all the goodies as if you had purchased directly from us. Right now, the pricing for the MacroLib is $119 for the desktop version. The pricing for the Windows Server version is set at 15% of the annual WPS license fee.

The documentation for MPExec can be found at:

MPExec requires WPS release 2.3.5. By the end of June, we expect to be able to begin fulfilling phone orders. Make sure you check our website for an announcement!

MPExec – Everything but the Documentation

I finally finished the programming for MPExec and have the runtime notes for the log looking just the way I want. It’s a nice little system to run concurrent WPS processes on a windows work station or server and get full utilization of your processor cores. I have a log file that you can view where we are running eight processes on four cores. You will want to look at the last thirty five or forty lines in the log to see the summary of the multi-threading for all eight processes. You can view the log at:

Over the next few days, I’ll be writing the documentation for MPExec. Installation is pretty easy and the only configuration required is to write a few lines to your file. Any code changes to your existing programs will be pretty simple. There’s only four new commands so you can multi-thread your WPS program without much work.

Currently, MPExec requires WPS version 2.3.5 which is the latest release. We use some new functionality in this release to get our code to execute the way we want and not have to use an external DLL or .EXE file. Hence the requirement for the latest release of WPS.

We also intend to get MPExec running in the Unix and Linux platforms as well. We will announce that availability at a later date.

Finally, we intend to include MPExec as part of the macrolib that we include when you license WPS from MineQuest. The new macrolib will include the Bridge to R for WPS, XMLRead and XMLWrite as well as MPExec. If you have licensed WPS through another reseller or through WPC directly, we can sell you a license for the MineQuest macrolib separately. Contact us directly for pricing.