The Perkin-Elmer Years: When Intuition Stopped Being Enough

In my last post, I discussed how a bit of curiosity (and a lot of ingenuity) sparked the first computing experiments in seismic imaging. This time, I'll explore what I think of as the Perkin-Elmer era — a period that did a lot to shape the culture and technical practices behind what we now do at Viridien.
 

Welcome to the Machine

In our early, pre-computer days, processing teams could get far with curiosity and a bit of trial-and-error — and some did, for a while. But the real change, the point where our work started to look like the industrial, scalable model we rely on at Viridien today, came when the Perkin-Elmer machines showed up in the late 1970s: 32-bit minicomputers with early integrated circuits, replacing earlier digital systems built on discrete transistors and small-scale integration, which had in turn succeeded the analog equipment of the 1950s. They were a great fit for seismic processing, not just because of raw performance, but because they imposed a way of working — algorithm-driven, step by step, with inputs and outputs you could explain and reproduce. That discipline, more than the hardware itself, is what changed things. 

When I joined the Companie Generale de Geophysique, later renamed CGG — now Viridien — in the early 1990s, you could still encounter those machines in the field, because new-hire engineers were sent to acquisition crews first, to understand where the data actually came from (and I suspect also what the culture of the company was all about). My first crew was in India, specifically the Thar desert in Rajasthan, a few hours from the hilltop city of Jaisalmer. There I met Alan Clint, who joined CGG in London in 1989 and already had postings in Syria & Malysia before India. (Both of us are still with the company decades later, which makes us among the longest-serving people in the organization.) 

Alan was a hands-on processor who also managed the processing center in Jodhpur. His team used a Perkin-Elmer 3210 to run interpretation software and a 3280 for seismic processing. The Perkin-Elmer 3200 series were already well past their prime, but still running reliably in places where newer hardware rarely reached, for reasons ranging from import logistics to the simple fact that they worked. 

The adventure was real — human, logistical, and technological in equal measure. But the direction was already clear: computing had entered the picture in the 1950s and had become exponentially more advanced. Things were going to be different.

Coming of Age

Those early Perkin-Elmer systems were not forgiving, and that turned out to be useful because of the discipline it imposed on us. 

With an analog kit, a good operator could often feel their way through a problem by tweaking a gain here, adjusting a filter there, and experience would carry you some of the way. With digital machines, that was over — someone needed to write code to achieve anything. That is where excellent software, capable hardware, and the skill to push both to their limits started to become non-negotiable and a business differentiator. 

Since very few industries shared our same compute requirements, we had to develop all the skills needed to support this activity anywhere around the world: the capacity to design and optimize anything, from datacenter infrastructure and hardware selection to application stacks and job sequences. Over the years, well before the Internet, Big Data, Hyperscalers or AI, we became capable of deep multidimensional optimization of our operations, something we still do today. 

Now we scale workloads across multiple regions and heterogeneous architectures, which would have been science fiction to the teams running those 3200 series systems. AI is introducing a major change too, but then again, as you will see in the next episodes of this blog, so did clusters in 1999 and GPUs in 2007, to name a few. Understanding and leveraging new technologies is part of the game and contributes to Viridien's success over close to a century. 

But the expectation of accurate, repeatable quality output always remains the same. And the skills necessary to achieve that result will always make a difference.

The Human Factor

The machines didn't run themselves, and three distinct roles emerged to make sure they didn't have to. Job titles have evolved and keep evolving, but the roles themselves are still recognizable in how Viridien operates. 

Operators: Keeping Things Running 

Operators were, in retrospect, doing Site Reliability Engineering before anyone had thought to name it. They knew the quirks, managed the tape mounts and job queues, and somehow kept the systems running even when the hardware was only half-cooperating — which, on aging 3200 series systems running in a desert processing center, was not a hypothetical. Over time they shaped a belief that is still embedded in how we work: throughput is not a metric you report, it is something you earn through practice and lose through complacency. 

Programmers: Talking to the Machine 

Programmers were the bridge between the physics and the hardware, and the constraints were significant: tiny memory, ridiculously low processing and storage capacities, bare-bone programming and execution environments. Yet they built algorithms that became the backbone of early seismic imaging, mostly because they had no choice but to understand both the geophysics and the machine deeply enough to make them work together. That pragmatism has not left us: at Viridien, performance matters — we are both an R&D operation improving algorithms and images for our clients all the time, and an industrial HPC user keenly aware of the cost of the products we deliver. 

Systems Engineers: Keeping It Professional 

Systems engineers were the ones who turned individual competence into repeatable process — documenting sequences, aligning operators and programmers, and making sure that what worked once could be made to work again. They are the ancestors of our workflow governance, our container standards, and our HPC architecture principles, and the thing they demonstrated most clearly is still true: past a certain scale, individual brilliance is not enough. You need process you can rely on, and someone whose job it is to build and maintain it.

A Legacy That Began Decades Before the Name

Looking back at those years, what is striking is not how much has changed but how much has not. Reproducibility as the default, not a stretch goal. Workflows clear enough to hand off and re-run. Operations treated as part of the engineering job, not a support function bolted on afterwards. Respect for the way hardware constraints shape algorithmic choices, and vice versa. None of that arrived with cloud computing or containerization — it was worked out in machine rooms full of cooling fans and reels of magnetic tape, by people who had no abstraction layer to fall back on. 

All we have done since is carry it forward, and for some of us who went through that journey, it has been quite a trip.

Why This Story Matters Today

Viridien is not a company that discovered HPC recently. We have been doing this, at scale, under operational and scientific constraints that most compute providers have never encountered, for the better part of a century. The teams, the processes, and the architecture principles described in this post are not historical artifacts — they are how we operate today in multiple large industrial HPC sites around the world. 

The next episodes of this series will cover how that foundation evolved through the mainframe and cluster era, the GPU transition, and what we are building now. If any of that is relevant to what you are working on, or if, like myself, you went through those years, I am always glad to compare notes.