alexblogimage

Every mature MVC application has that one model that’s grown out of control.  The table has 20 columns; there are user preferences stored in it alongside system information; it sends email notifications and writes other models to the database.  The model encompasses so much application logic that any new feature is likely to have to go through it.  It’s the class that makes developers groan whenever they open it up.

How did we get here?

Web applications usually start out with a single purpose, to display a single type of data – maybe it’s Article for an online journal or ClothingItem for a fashion retailer.  It’s common for MVC practitioners to take concepts from their product whiteboarding sessions and directly translate them into database models.  So we start out with a database model that represents a central concept in the application, and as more business requirements emerge, the cheapest way to accommodate them is to add columns to the existing model.  Carry this out over time and you end up with a God Object.

The problem from the start was taking the casual, loose concepts sketched out at the product level and putting them in the codebase.  Software engineers should be well aware that the concepts people use in everyday life and thinking are terribly imprecise and loaded with implicit assumptions.  Highlighting implicit assumptions is often a software engineer’s key contribution, so it’s a wonder we take these concepts from the product level and embed them in our code.  It’s just asking for hidden edge cases to need clarifying logic shoved into the existing class.

The concept of Folk Psychology is illuminating here.  Folk Psychology refers to the innate, loosely specified theories that people have about how other humans operate that they use to infer motivations and predict behavior.  These “folk” theories work well enough in the context of everyday human life, but are not scientifically rigorous and contain blindspots.  Similarly, people make use of “folk object models” in software businesses.  These are the informal concepts people construct to discuss software with other humans – the words product managers use with software engineers, the boxes drawn on the whiteboard.  They work well enough when discussing concepts with other humans, who can be generous in their interpretations, but can fall apart when formalized as code.  These concepts are a useful starting point to frame the product features, but from an OO perspective are too broad to be used as classes.  They tend to accumulate logic since they implicitly encompass so much of the problem domain.

Much as the first obstacle people have to overcome when learning to code is to take their thoughts and explicitly formulate them as steps in an algorithm, experienced software engineers need to take folk object models and break them down into explicit components that can be used as classes.  In the product domain, we may start with a broad “User” concept concept, but as we dig deeper we’ll discover different pieces of logic that would be better served as separate classes- a billing preference, a current status, or notification settings.  Each of those will require their own logic to meet product requirements, and if we don’t separate them out to make space for the logic, we’ll incur bloat.

People often think that data modeling is about encoding the business concepts in software, but really it’s about using model classes as tools to construct a system.  Often codebases are better served when large models are broken into components that each address a specific piece of domain logic.

This article was written by Alex Kudlick.

mulyantoblog

Rescale offers various software with on-demand licensing.  These software are popular because of the pay as you go nature.  Not only do these software provide an easy way of accessing the software, but many software are priced in such a way that they encourage running on more cores and therefore providing a faster turnaround time to solution.

As far as on-demand software pricing goes, most software fall in 4 general per-hour pricing categories:

Proportional – you pay proportionally to the number of cores you use
Flat Rate – you pay a flat rate per hour, no matter how many cores you use
Capped – you pay proportionally up to a certain number of cores and pay a flat rate after that
Discounted – you pay a nominal rate for the first core and pay less for each subsequent core

The pricing model is shown in the Rescale UI (In this case it’s capped)

It is clear that a proportional rate does not benefit the customer when scaling up to many cores, however, the other three pricing models may benefit the customer by running more cores.  In reality the benefit is based both on the pricing model as well as the scalability of the job and software.  The scalability is the assumption that a given job will run faster on more cores.

What I intend to show in this blog post is that certain software pricing models provide the opportunity to run your job faster and on more cores while actually paying less.

Nomenclature
This is not a scientific paper, however I will provide some equations to illustrate some of the concepts related to price and scaling. To make the equations easier to understand here are some definitions

hw Hardware
I Number of iterations
k Some per-unit constant
K Some constant
N Number of Cores or Processes
p Unit price
P Price
sw Software
t Time per iteration
T Total Time

The Problem
An engineer has a model and wants to know the most cost efficient way of running his model on Rescale.  Because the cost of the job is a sum of both hardware and software cost, we need to take into account the pricing models for each.  The hardware cost is charged by Rescale on a proportional basis.  The software cost is priced depending on the software vendor’s (ISV’s) pricing model.  The total hourly price would look something like:

Ptotal = Phw + Psw

The total cost of the job would be the product of the hourly price and the duration of the job.  This is the value we want to minimize.

Total Cost = (Phw + Psw) * Total Simulation Time

As explained before, we can say that the time it takes to run the job and the per hour prices are a function of the number of cores used.

Phw = f(N) = phw * N

Psw = f(N)

T = f(N)

With this information, we can now try to optimize the cost of the entire job.

Hardware Pricing
Hardware is charged by Rescale on a proportional basis.  The per hour price is based on a per core hour rate which differs between the different core types and pricing plans available on Rescale. Simply put, the hourly hardware price equation is the product of the per core hour rate and the number of cores:

Phw = phw* N

Software Pricing
On-demand software pricing is set by the ISVs.  As discussed before, there are several different pricing categories.  The equations for obtaining the hourly software price as a function of the number of cores are fairly straightforward:

Proportional Psw = k * N
Flat Rate Psw = K
Capped Psw = min(K, k * N)
Discounted Psw = K * f(N)
For Example: Psw = K * N.9

Simulation Time and Software Scalability

The time to run a simulation over N processes / cores can be approximated by the following equation:

Tsimulation = Tserial (1 / N + k1 * (N – 1)k2)

Where Tserial is the time it takes to run the simulation in serial.  The blue part describes the raw compute time while the red part describes the communication overhead.  If you are interested in the justification, read on.  Otherwise skip to “Costimizing”.

The details:
There are many ways of modeling scalability.  Amdahl’s law is often quoted as representing scalability relative to the different parts of the simulation which benefit from scaling over extra resources.  It does not, however, address how to define or quantify the benefit of extra resources.  In our case, we have a fixed sized model and we want to know how it will perform when we scale it over an increasing number of hardware cores.  So, for illustrative purposes, let’s make a few assumptions:

  1. The simulation is iterative
  2. The simulation is distributed over N processes on N cores
  3. Each process requires information from other processes to calculate the next iteration and uses MPI
  4. The number of iterations, I, to finish the simulation is independent of N
  5. The number of compute cycles required to complete an iteration is independent of N

Given these assumptions, the time it takes to complete an iteration is:

titeration = tcompute + tcommunicate

if compute and communicate are synchronous operations.  Otherwise, when considering them to be asynchronous (non-blocking) operations,

titeration = max(tcompute, tcommunicate)

Lastly the total compute time is easily calculated from the iteration time and the number of iterations.

T = titeration * I ∝ titeration

Here we assume that each iteration is more or less equal.

Compute Time
For compute time, assumption (5) gives us

tcompute = tserial / N

This is telling us that given no communication overhead, our model will have linear strong scaling.  It also tells us that the larger the model (tserial), the larger tcompute and the less detrimental effect communication overhead has on the relative solution time because of the dominance of tcompute.  The result is that larger models scale better.

Communication Time
The time to communicate is more complicated and depends, among other things, on how fast the interconnect is, how much data needs to be communicated, and the number of processes N.

Let’s simplify and break it down.

The communication time between two processes can be defined as 2 parts: the communication overhead (latency) and the data transfer time (transfer).  So, to send one message from process to another we can for now simply define:

tmessage = tlatency + ttransfer = tlatency + (transfer rate * message size)

The transfer rate is lower for small messages and increases as the messages become bigger,  peaking at the bandwidth of the interconnect.  We can assume for now that the latency is constant for a given interconnect.

To see the effect in practice, this paper (http://mvapich.cse.ohio-state.edu/static/media/publications/abstract/liuj-sc03.pdf) investigates the performance of MPI on various interconnects.  What the paper shows is that for small message sizes, the communication time is more or less constant.

tmessage ≅ k

With this knowledge we can infer that the total time to communicate depends on the number of messages being sent by each process.  The number of messages sent in turn depends on the number of processes because, presumably, each process communicates with every other process.  An equation that can then be used to model the number of messages sent is:

Messages = k1 * (N – 1)k2 ∝ tmessage

Furthermore, we can normalize k1 by the number of iterations and therefore tserial

tcommunicate = tserial * k1 * (N – 1)k2 ∝ tmessage

Putting it Together
The total time for the simulation is

Tsimulation ∝ titeration = tcompute + tcommunicate

when compute and communication are synchronous (blocking) operations. By substitution,

Tsimulation = Tserial (1 / N + k1 * (N – 1)k2)

Obtaining the Constants
The constants can be obtained through fitting the equation to empirical benchmark data.  The communication overhead model, which is presented here, is by no means an end-all.  It has been shown from our internal benchmarks that this equation fits well with almost all scaling numbers.

Furthermore, we have found that usually k2 ≅ 0.5.  We have also found that k1 is a function of model size, interconnect type, and processor performance.

Costimizing
Let’s go back to our total cost equation:

Total Cost = (Phw + Psw) * Tsimulation

The total cost now depends on the software pricing model used.

Total Cost = f(N) = (phw * N +Psw) * Tserial (1 / N + k1 * (N – 1)k2)

An Excel calculator can be found here [link]. Here is an example output:
mp2

How We Can Help
Rescale’s support team can help you estimate the right number of cores to run your simulation on.  It is not always feasible to run benchmarks for every single use case, and from the example above, being a few cores off doesn’t have a huge impact on the cost you save.

What we want you to be aware of, is that with a well scaling software and a flat rate or capped pricing model it is often more cost efficient to run on more cores.

This article was written by Mulyanto Poort.

manorrescale500x233-2

San Francisco, CA – Manor Racing is partnering with San Francisco based Rescale as a key technology provider for its 2016 FIA Formula 1 World Championship challenge.

Manor Racing will use Rescale’s cloud high performance computing (HPC) platform to enable trackside simulation on a whole new scale for the team. Working in tandem with Manor Racing’s existing race strategy simulation software, the Rescale cloud HPC platform will enable its engineers to evaluate thousands of simulations and strategies, placing the team to be at the cutting edge of innovative decision making during a Grand Prix weekend.

The whole process is executed from a laptop web browser by Rescale’s massively scalable cloud infrastructure and computer environment.

Dave Ryan, Racing Director: “We’re aiming for steady progress up the grid in the seasons ahead and our new partnership with Rescale is key to helping us engineer that transformation. It’s all about optimisation and the areas of mathematical modelling and computational fluid dynamics (CFD) can help provide rapid growth and constant evolution. Evaluating results in real-time using Rescale’s cloud HPC platform gives us a real breakthrough in our simulation capabilities, and without adding weight to our trackside infrastructure.”

Pascal Wehrlein (GER) Manor Racing MRT05. 18.03.2016. Formula 1 World Championship, Rd 1, Australian Grand Prix, Albert Park, Melbourne, Australia, Practice Day.

Pascal Wehrlein (GER) Manor Racing MRT05. 18.03.2016. Formula 1 World Championship, Rd 1, Australian Grand Prix, Albert Park, Melbourne, Australia, Practice Day.

Pascal Wehrlein (GER) Manor Racing MRT05. 18.03.2016.
Formula 1 World Championship, Rd 1, Australian Grand Prix, Albert Park, Melbourne, Australia, Practice

The Rescale team have quickly understood the complexity of Formula 1 racing, where every thousandth of a second counts.

Rescale CEO Joris Poort: “Using the Rescale platform requires zero IT footprint trackside. With just a laptop and an internet connection, Manor Racing has a global computer platform at their fingertips to provide a strong competitive edge in simulation. By using Rescale’s cloud HPC during the race in real-time, the engineer is provided with an equivalent of a semi-truck full of computers, instantly deployed from their laptop. Putting in place a physical high performance compute cluster would have cost millions of dollars in upfront capital investment.”

manor3smallcombined

Top: Pascal Wehrlein (GER), Bottom: Rio Haryanto (IDN). Manor Racing MRT05. 18.03.2016. Formula 1 World Championship, Rd 1, Australian Grand Prix, Albert Park, Melbourne, Australia, Practice Day.

Joris calls the partnership between Rescale and Manor Racing a perfect match. “The cloud market is moving at the speed of Formula 1. We are continually challenging ourselves to enable our customers to achieve better results faster by leveraging and deploying the latest technologies in computing hardware and simulation software to the industry leaders. We are now doing this with Manor Racing and not only deploying cutting edge technology, but also technology that delivers direct and tangible results through the sport. It’s very exciting for all of us.”

About Rescale
Rescale is the world’s leading cloud platform provider of simulation software and high performance computing (HPC) solutions. Rescale’s platform solutions are deployed securely and seamlessly to enterprises via a web-based application environment powered by preeminent simulation software providers and backed by the largest commercially available HPC infrastructure. Headquartered in San Francisco, CA, Rescale’s customers include global Fortune 500 companies in the aerospace, automotive, life sciences, marine, consumer products, and energy sectors. For more information on Rescale products and services, visit www.rescale.com

About Manor Racing
Manor Racing is small but is aiming to fight big in 2016. The team has new blood alongside Manor Racing’s loyal pros. All drawn to a love of Formula 1’s original essence. Formula One is the sum of countless components – mechanical and mental. It requires mental agility – swift problem solving. It requires mental strength – battling past challenges and disappointments. For Manor Racing it is about meticulous attention to detail, eking out every single opportunity to close every single gap. Car and driver, factory and team. All spurred by imagining what might just be possible. It has partnered Mercedes-Benz for race power and Williams for transmission. New owners have put Manor Racing back on track – literally and figuratively – with solid planning and sound investment. It is in good shape, ready to compete, ready to race.

MANOR RACING MEDIA │ Tracy Novak, PR, Communications & Brand Director … M: +44 (0)7701 382031 …
E: tracy.novak@manorracing.com
RESCALE MEDIA │ Zack Smocha, VP Marketing M: +1-408-202-0640 E: zack@rescale.com

This article was written by Rescale.

avlrescale
San Francisco, CA – Rescale is excited to announce the availability of AVL EXCITE™ on Rescale’s simulation platform through a collaboration with AVL, the world’s largest independent company for the development of powertrain systems with internal combustion engines as well as instrumentation and test systems.  This addition to the Rescale platform further strengthens the AVL and Rescale collaboration, with AVL EXCITE™ joining AVL FIRE™ as one of Rescale’s critical software offerings.

The AVL EXCITE™ product family is a powertrain-oriented rigid and flexible multi-body dynamic analysis solution that provides advanced techniques used to calculate the dynamics, strength, vibration, and acoustics of combustion engines, transmissions, and conventional or electrified powertrains and drivelines.   AVL provides a single simulation environment for all phases of the engine development process and for all structural dynamics related analysis tasks.

On Rescale’s platform, AVL EXCITE™ users can now run analyses on high-end hardware at anytime and from anywhere in the world with the ability to seamlessly collaborate on projects with colleagues around the world.  Users execute simulations using their existing AVL EXCITE™ licenses with Rescale’s on-demand high performance computing (HPC) hardware, with 30+ global data centers, having the ability to interface to 3rd party CAE software including Finite Element Analysis (FEA) and optimization.  This addition to the Rescale and AVL collaboration allows users to execute multiple simulations in parallel using Rescale’s dynamic pay-per-use HPC platforms, leveraging built-in administration and collaboration tools designed to improve and speed-up the simulation process.

“Collaboration with Rescale enables AVL users’ community to access AVL software through flexible approach on Rescale cloud computing environment. This is an important step towards offering seamless access to our powerful simulation capabilities.” Dr. Gotthard Rainer from AVL, Vice President Advanced Simulation Technologies.

“We greatly value our collaboration with AVL and are thrilled to add AVL EXCITE™ to the Rescale platform, ” says Joris Poort, Rescale CEO, “With Rescale’s turn-key environment, AVL users can leverage our wide range of scalable hardware to accelerate their entire EXCITE™ workflow.”

For users interested in taking advantage of AVL EXCITE™ in the cloud using Rescale’s platforms, you can contact Rescale and AVL using the resources below. To begin running AVL EXCITE™ immediately, you can create a free Rescale account by going to www.rescale.com/signup.

AVL
Email: info@avl.com
Phone: +43 316 787 0

Rescale
Email: info@rescale.com
Phone: +1 415 589 0530

About AVL:
AVL is the world’s largest independent company for development, simulation and testing technology of powertrains (hybrid, combustion engines, transmission, electric drive, batteries and software) for passenger cars, trucks and large engines.

Scope of Business:
Development of Powertrain Systems: AVL develops and improves all kinds of powertrain systems and is a competent partner to the engine and automotive industry. In addition AVL develops and markets the simulation methods which are necessary for the development work.

Engine Instrumentation and Test Systems: The products of this business area comprise all the instruments and systems required for engine and vehicle testing.

Advanced Simulation Technologies: The developed simulation software is focusing on design and optimization of powertrain systems and covers all phases of the development process.

For more information on AVL, please visit www.avl.com.

About Rescale:
Rescale is the world’s leading cloud platform provider of simulation software and high performance computing (HPC) solutions. Rescale’s platform solutions are deployed securely and seamlessly to enterprises via a web-based application environment powered by preeminent simulation software providers and backed by the largest commercially available HPC infrastructure.  Headquartered in San Francisco, CA, Rescale’s customers include global Fortune 500 companies in the aerospace, automotive, life sciences, marine, consumer products, and energy sectors.

For more information on Rescale products and services, visit www.rescale.com.

This article was written by Rescale.