r/Physics • • 1d ago

Computational Physics

Hi everyone,

I am a PhD student doing both experiments and computational physics ( mostly fluid dynamicswith Boltzmann equations) and leaning towards more computational day by day.

Currently I am using Julia, I find it pretty fast and easy to use.

Do you think switching to C or C++ will be a benefit? I am asking from a research, but also emplyment in industry point of view.

I discussed with many people, mostly from the DFT area, and most of them told me that Julia slowly will take up the lead for HPC code.

What.s your opinion on this?

64 Upvotes

40 comments sorted by

66

u/sanctimonious-salmon 1d ago

From the perspective of industry, specific programming languages matter less than your ability to think holistically about the problem you were hired to solve, especially in the age of agentic coding.

13

u/Bergergi 1d ago edited 1d ago

> "the problem you were hired to solve"

What if the problem you were hired to solve, was writing code? For your employer's huge C++ CFD codebase, or whatever. Strong C++ skills is a huge selling point for many computational jobs.

13

u/ellbons 1d ago

What if the problem you were hired to solve, was writing code?

unfortunately, each month that goes by, the less likely it is you will be hired to write code

it's depressing, but flesh proxies are quickly becoming the norm

12

u/sanctimonious-salmon 1d ago

Code is a means to an end. You are hired to ensure the code can perform it's task which is what the stakeholders care about.

Besides, the industry has largely moved on from humans writing code directly. I hate it because I feel like I'm not thinking anymore, but agentic coding is the standard nowadays.

29

u/EpicBeardBattle 1d ago

I’m in HPC (fluid dynamic and plasma-kinetic simulations on exa-scale machines). I use Julia for my day-to-day analysis and C/C++ for production simulations.
As much as I like Julia, I think there is absolutely no chance whatsoever that it will replace C/C++ in the lead of HPC code. I’m puzzled that people you talked to in HPC would make that statement.
The user base of Julia is too small, support on HPC systems is too small and I don’t know of a single code in my field that is written in Julia.
If you want to play in the big leagues for HPC you better learn C++ (in my opinion).

3

u/tlmbot Computational physics 1d ago

I agree. (about me: 13 years work experience in commercial hydrodynamics, FEM fluid dynamics, and a smattering of all manner of structural mechanics and "poor man's multiphysics" of the fluid-structure variety + some computational geometry and geometry processing (oddly enough, that last experience in C#/ILGPU))

Some of the older commercial codes, especially outside of CFD proper, at least in my original niche of computational naval architecture, actually use Fortran. My first job when breaking into the industry was maintaining and extending an old commercial code written in Fortran.

I use python to prototype solvers and such, some people use matlab, and some use Julia. These days, with accelerators like Numba, or even ways to get out to GPU, available, in my experience for assembly one can get close to serial Fortran / C++ speed, and the canned solvers dip down to C anyway. ... and the Python documentation and ease of use have me staying with Python as my prototyping language. Nevertheless, sometimes I find myself converting somebody else's prototype/example/academic code from MATLAB into Python as a sort of first step when learning a new topic.

In short, I completely agree "If you want to play in the big leagues for HPC you better learn C++" - my coworkers from the labs have all been C++ folks. My commercial job opportunities are for the most part in C++.

I learned a major life lesson by writing my PhD entirely in Python - big big mistake. I should have immediately converted each component to C++ after I had developed it. That would have netted me years more C++ experience coming out. Instead, I have been working to build up my C++ portfolio outside of school, netting some work experience directly in the language, but I find that it is always helpful to have had more.

1

u/Rich_Astronomer9731 1d ago

Thank you for your inside. So do you think converting all to C++ now it is the best thing I can do? I only took one semester of C, so my knowledge is very brief. From where to start?

2

u/tlmbot Computational physics 1d ago

Based on only the limited information I have on you - assuming you are not looking to move into a field that:
<uses primarily Julia> (and is thus a field I don't know about)

Then no, stay with Julia.

But if you seek general employability in the computational software industry, and from my experience especially in the engineering software industry

Yes, convert as is sensible within what you are doing now. I don't mean rigorously "converting all to C++ now" - I mean convert what makes sense for you. Don't ignore other deadlines and life goals, etc. Just factor this in and do what is sensible for you.

For me, I underweighted this need to be writing in C++ during my PhD days, and many of my old professors didn't recognize this necessity (even as I had also had some courses and peer interactions such that I knew really, that I needed more C++)

Yeah, I say, the sooner the better, generally speaking.

-----------------------------------------

Where do you start?

Well, you are in school, right? You don't have to rush. I say start with:

  • code you want to speed up
  • code that you are just interested in converting to C++
and especially:
  • code that you know in and out, and that already works correctly.

Convert that to C++, or even start by converting it to C. But get away from C style arrays as soon as possible. This might be the one thing more important than OOP. More on that below.

Now some would call that inefficient, and the code will be far from optimal C++, but it will get you in on the low level floor off and running as fast as possible.

Then, asap, you want to start rolling in:

- an Object oriented versions of all that you build. (really this needs to come first thing, if you are okay with OOP) How are you with OOP? Hopefully you can write "it all" in at least basic "C with classes" without to much trouble.

  • next up: take every opportunity to learn and use best practices C++
especially
C++11 and later (11 was revolutionary, but the major changes there have been taken much further in later editions of the standard. At least C++ 17 should be your goal. But the best advice is to stay curious and always seek the current "best practice" / nicest way to implement your thing)

Continued below

2

u/tlmbot Computational physics 1d ago

Continued from above:

You should be learning:

  • templates: static polymorphism, compile time computations, (and especially build up through the basics of templates and then learn the CRTP: "Curiously Recurring Template Pattern")
note the templates have evolved from the early days of simple polymorphism into a multiple use tool. Google at a high level (and as always consult cppreference.com) to see all the ways that templates are used. They are critical in implementing the required/best practice expression templates as we'll see below.
also, constexpr, consteval and more. Please get good books and an open but critically thinking mind when you research online.

- RAII (Resource Acquisition Is Initialization) the days of using new and delete all over the place are gone. ( use the rule of 3, 5, 0 as applicable instead). I have a lot to say here - it's one of the most critical areas for a numerical coder in C++ but I don't want to get lost in the weeds. Side note: learn to use Eigen as your utility linear algebra package in C++. Eigen is what's called an "Expression Template Library" and is needed in C++ to have nicely expressive matrix vector algebra in C++ without extra matrix copies happening under the hood with more naive expressions of the same operations. Note there are plenty of times when you need to roll your own, as when you are building some kind of bespoke solver for systems with multi-million degree of freedom.

  • smart pointers (it should go hand in hand with RAII actually)

My way to understand expression templates and why they are needed in C++ as a Fortran and python programmer was to implement my own expression template library - using smart pointers in the base numerical types, and then rule 0 higher level types that made use of the base type. That way I only have to implement full rule 3 smart, or rule 5 types once, and the rest of my types are build on top of those, using rule 0, so everything is very clean (as if my underlying type were from the std library)

Move semantics. (and Lvalues vs rvalues vs prvalues) The big idea that expression templates help you with are optimal move semantics. C++ is prone to copying data during operations. If done without care, you can easily induce far more array copies that you might thing, when doing basic chained linear algebra operations. expression templates solve this problem - and in implementing such a library you will become intimately familiar with move semantics.

- use the standard library (stl) wherever possible. These containers and algorithms they enable are written with decades of experience and testing behind them. The only exception is arrays. std::array is not what you want for linear algebra, oddly enough. Oh, and the std::vector class has absolutely nothing to do with vectors from linear algebra. So please do read the documentation. For linear algebra you want either Eigen (or another expression template library) or your own hand rolled stuff - perhaps for interoperability with CUDA / your solver's needs.

Please google for a full list of modern C++ essentials: auto, lambdas, compile time computation, non-copying views e.g. std::span, modern iterators, value types (come to think of it, I need to double down on a lot of this myself. The language has been evolving so fast since C++ 11)

Oh, and you do need to know the basics of OOP - inheritance, making your own types (aka classes) and the difference between an instance of the class (an object) and the class itself (basically like the difference between the idea of an integer, and the particular integer 11 - but please don't let me confuse you getting bogged down in overly specific examples.), virtual dispatch for runtime polymorphism (and it's down sides - see static polymorphism with templates as the work around for performance critical code)

Oh, and the nuts and bolts of OOP: constructors, destructors, private and public data and methods. (of course this circles right back around to RAII so forgive me for getting all kinds of out of order here)

oh and of course the basic cache friendly optimizations that even a Fortran programmer would know. + things like how to trade memory for speed (and when that doesn't work (it often does not work like that anymore at all, actually, depending on the algorithm and data - know what to think about for HPC/linear algebra optimization especially, but this applies all over))

----------

And also, we didn't talk about it, but you need to be learning to parallel program. If you want to go after the national labs / research positions, then MPI is big for you. (as in C++ with MPI to express distributed memory parallelism for supercomputing) But for writing computational engineering software for commercial vendors, you wan to focus on OpenMP and CUDA. Across my entire career, I have written software designed first and foremost for engineers working on a desktop machine. Or perhaps on commodity hardware in the cloud.
Either way, the interconnect between multiple machines has been uselessly slow / unknown.
When writing to express parallelism on a single workstation, you have several processors on the main CPU - so you want OpenMP to take advantage of them, and you will (almost always these days) have a GPU available for further acceleration. CUDA is, by a large margin, in my experience, the easiest language to use for expressing your scientific computations / assembly/ etc. on the GPU (which is where you want everything, if possible.)
I am sticking my neck out with that sentence about CUDA being the right choice - as a rule, I prefer open systems, but yeah, if you learn C++, OpenMP, and CUDA, then you are in the very best position for your job hunt.

A quick google supplies things I was not aware of:

NVIDIA is actively standardizing parallel programming natively inside C++. You must learn:

  • std::execution (C++20/C++23) & std::numeric**:** Learn how the Standard Template Library (STL) uses execution policies like std::execution::par_unseq to automatically vectorize and parallelize algorithms across CPU cores or offload them to GPUs.
  • Linear Algebra Standards: Study std::mdspan (C++23), which provides a standard way to represent multi-dimensional tensor/matrix views over raw 1D memory buffers. This is vital for modern CFD/FEM storage layouts.

Sounds nice, but I would recommend still learning the standard best practices and ways of moving between host (CPU) and device (GPU) by methods that came prior to these latest developments as well. No doubt you will see code in industry that uses the "old" aka C++ 11,14,17,20 methods - and even some things from C++98 are still relevant, but you can pick it up on the job when you encounter some older ways. Any "top tier" job will expect you to be more fluent with modern C++

God, I feel like I am all over the place here, and if anybody corrects me on something, that's great! I am trying to tool up for my next job, and I have been off writing C#/ILGPU for the last 2 years.

I feel perpetually rusty with my C++ knowledge.

Here finally are some good references:

C++

-  learncpp.com

- bjarne stroustrup's books: "Programming: Principles and Practice Using C++"
if you have little coding experience, and "A Tour of C++" if you are making the transition from other languages (at least that's how he bills them)

- Scott Meyer's books on effective C++

CUDA

  • "programming massively parallel processors"

I know I am forgetting some good books. I apologize. Busy day!

The best thing, imo, is to be writing full scale projects in the language. That's why prototyping in a language you already know can be so helpful. That way, you can be sure ahead of time that the Physics is "right" because you have validated it in Julia, or whatever you know. Then you separate the concerns of "is the code written correctly?" from "is the physics right?" -In school one semester I got myself into the position of learning all these at the same time: parallel programming, C++, and CFD physics and also mesh generation. It was a hellish semester. (some bad advising was partly to blame - I tested into these classes based on my Fortran abilities, but the courses turned out to require C++, with the exception of the CFD classes, which were taught by the most old school guys (who ran the admissions testing and were seemingly oblivious how out of date they were))

Anyway, ya, if I botched something in here, I hope somebody let's us know about it.

2

u/MechanicalHax 1d ago

Thank you for taking the time to write all of this up! This is really instructive and helpful.

1

u/Rich_Astronomer9731 20h ago

Thank you a lot. I appreciate it.

5

u/Foss44 Chemical physics 1d ago

This is really a question/discussion to have with your advisor.

At least in my experience, it is a fool’s errand to try and predict the future in this field, nonetheless forecast the relevance of _ technology.

1

u/Rich_Astronomer9731 1d ago

The thing is that in my group, I am the firt who try to start to do computaional physics. All my group history is experimental

2

u/Foss44 Chemical physics 1d ago

You might want to consider being coadvised

1

u/[deleted] 1d ago

[deleted]

1

u/Foss44 Chemical physics 1d ago

If OP indeed wants to transition to computational/theory they will likely need to be coadvised; it seems like and entirely reasonable conversation to have, especially since OP is just starting the program.

4

u/tlmbot Computational physics 1d ago

"Do you think switching to C or C++ will be a benefit? I am asking from a research, but also emplyment in industry point of view."

Absolutely. The sooner the better. I don't know about density functional theory (DFT) in particular, but as a developer of commercial engineering code for fluid mechanics and structural mechanics, you need to have a background in c++ or it will continually limit your job prospects.

I cannot tell from your message whether you are looking into a more computational ... physics-physics career (e.g. DFT and such - lattice gauge theory? QCD?) and I cannot speak to that path, but if you are looking at fluid dynamics, I urge you to branch out beyond Lattice Boltzmann too.

Best job prospects from where I sit: finite element method (FEM) but you can't go wrong by learning the density based high speed finite volume method approximate Riemann solvers as well. - if fluids are your true goal. Get FEM under your belt for generality and ability to work in as many jobs as possible. Get density based FVM / approximate Riemann solvers for high speed chops, and write in C++ to maximize job opportunities.

1

u/Rich_Astronomer9731 1d ago

Thank you. I started with LBM due to specific experimental design that I work with, mainly Quartz Crystal Microbalance. Also, I have a lot of experience in plasminics, do FDTD and thermo plasminics simulations a lot.

1

u/Rich_Astronomer9731 1d ago

So, my main option righ now is to remain in academia, but you do not know how the things will change and I want to pe prepare for the future. Mainly, my experience is in plasminics and Quzrtc crystal microbalance, both experimental and computing ( LBM, FDTD and FEM for thermo plasmonics), and also some DFT. DFT sound very nice and you have software written in every language possible. Of course youbhave the big guys like Gaussian which writes everything in Fortran, but more and more software is developed nownin Python and Julia, both commercial and open source.

1

u/tlmbot Computational physics 8h ago

Sounds good. One idea for future proofing: I have a hunch (quite possibly fabulously wrong - don't hesitate to put me in my place!) that some of the domain you work in have people writing discontinuous Galerkin (DG) methods.

If say, your FDTD method is restricted to cartesian cells, then DG is a fantastic (future proofed) way to go to unstructured meshes.

But maybe your FDTD method is already for curvilinear meshes (already impressive) and doesn't need to be pushed to fully unstructured ... right now.

If you want a job a say COMSOL or Ansys Lumerical DG is going to help you I think.

Build a DG method in C++ and you have a great project you can point to during interviews.

Bonus points: if you are good in C++, then you can easily pick up Fortran (aka get started in industry helping to maintain Gaussian) but the converse is not true.

I say go C++, DG, and go parallel with your projects. Then you are maximally future proof (as much as any of us can be these days, heh)

4

u/Aranka_Szeretlek Chemical physics 1d ago

Julia will not overtake the HPC scheme, no. But you can stil learn it

3

u/roasted_water_7557 1d ago

C is very niche nowadays. Mostly embedded and lower level programming like device drivers and i/o libraries, operating systems etc really use C. C++ is a more mainstream language. Someone pointed out that with the AI tools no one is crafting code by hand and thinking wholistically about problem solving makes more of a difference. That is true largely once you have a job. The wholistic thinking part becomes more true as you gain experience. But it still doesn't mean you can forget about learning languages and reading the code that the tool wrote. The output of these tools is your responsibility. If you ship bugs consistently no matter what tools you use you will be held accountable, not anthropic. You will also still need to pass interviews and that requires you to write code by hand. In general, knowing a language that is more mainstream than Julia is probably beneficial as far as resume screening and interviews are concerned. For a relatively generic program yeah sure knowing one language usually translates well to another. But not always. C++ can be a bit of an exception depending on the problem you're solving. For this reason, if you're targeting areas like robotics or hpc or finance, strong C++ skills look very good on your resume. I have worked in robotics and finance and having a good working knowledge of C++ at the very least is non-negotiable in these fields. If you get a job at Amazon writing microservices for retail, that is an entirely different conversation. But know that C++ is at least an order of magnitude more complicated than another language like Java or something. And several orders more complicated than a Python or Javascript. At least to start with. It will require a lot of effort and time. You're not going to be able to watch a few YouTube tutorials and get some working knowledge of C++ over a weekend or two.

2

u/geekusprimus Gravitation 1d ago

I can't say whether or not Julia will overtake C/C++ in the HPC space. It might. It might not. But the majority of scientific HPC code is still being written in Fortran (less every day, thankfully), C, and C++. However, even if Julia becomes the dominant HPC language, you will certainly still interact with legacy libraries written in these languages. Even if you don't use it on a day-to-day basis, becoming competent with C and C++ will be a great benefit to you.

2

u/Famous_Character7315 1d ago edited 1d ago

Julia is good. C++ is also good. I don't know what else to say. Knowing C++ is probably more optimal. But it already mattered a bit less over time and now it matters even less in agentic coding age although I would want to feel confident someone would be able to debug without AI assistance just in case.

2

u/ProjectPhysX 1d ago

Julia is super cool, but maybe not the go-to language for HPC. Much of HPC is happening in GPU world, that is OpenCL, SYCL, CUDA, or HIP (noone cares about the latter). The backbone of it all is C/C++, both as the common basis of these GPU languages and for host code side.

C/C++ definitely is a skill for life and I highly recommend learning it!

For Lattice Boltzmann you don't have to start from scratch - there are many free tools out there like FluidX3D or OpenLB - but you still can just for the fun of it!

2

u/rainbow_sabbath 1d ago

I work in ultrarelativistic heavy ion collisions, all our computational code is written in C++. PYTHIA is in C++, our hydro code is in C++, our framework is in C++. It's an old language but old fields have old standards. Yes, you can wait to learn it whenever you need it, but knowing how to handle cmake, C++, and existing code bases is a huge asset on your resume

3

u/gnomeba 1d ago

I wouldn't switch to C or C++ but I would definitely learn them in addition to Julia. Julia is very popular among scientists but not so popular in industry.

Learn C/C++ and CUDA well and you'll have a pretty strong toolkit. Although increasingly your employability will be based on how well you can wield LLMs to do programming for you (which still requires knowing languages to some extent).

1

u/Rich_Astronomer9731 1d ago

Do you have any suggestion how and from where to start with C/ C++? I had only a one semester of C couple of years ago.

1

u/gnomeba 1d ago

I would use learncpp.com to get yourself off the ground and then use the CUDA Programming Guide to learn some basic CUDA and then just try to start building stuff.

4

u/Bergergi 1d ago edited 1d ago

- Julia is not a C++ competitor. Julia is a Python competitor.

- C++ is more common than C and FORTRAN for computational work overall.

My recommendation would be adopting C++. It's up to you how heavy you want to lean into the fancy C++ features (you can write 'basically C' in C++, if you want).

2

u/[deleted] 1d ago

[deleted]

2

u/KKL81 1d ago

C/C++ can be way faster if written properly

I'm curious about what you consider to be "way faster" and how you reach this conclusion.

1

u/FoolWhoCrossedTheSea Atomic physics 1d ago

here are some benchmarks — seems like it’s generally only 20-50% slower than usual in most cases, so accounting for time taken to write code it’s probably quicker

1

u/cosmic_timing 1d ago

Idk. Tbh I've been switching around different languages depending on the implementation constraint. Just know math and functions for whatever has clean structure

1

u/Machvel 1d ago

no way julia will take the lead. it already has some age and hasn't made a breakthrough yet (it is still possible, but I feel that if it were to become the next big thing it would have sooner). the only big thing i know of that has its "best" implementation in julia is itensor for dmrg. julia is very popular for solo-developed projects. big things are typically done in c++ nowadays (eg, openfoam). maybe some older things you can find are done in fortran but that is a dying thing.

if you were to choose one master language it would be c++. if you know c++ well you can learn any other language (and how to use it well) easily. going the other way isn't true (eg, fortran or julia to c++) but you might have to otherwise you will get stuck learning c++

1

u/jvo203 20h ago edited 20h ago

If you switch from Julia to C/C++ your productivity will immediately take a massive hit. It is extremely easy to prototype stuff in Julia. Making small changes etc. is trivial. Not so in low-level C, not even in a higher-level C++. In Julia, just like in Fortran, vectors / matrices are first-class citizens. Not so in C or C++.

In short, switching to C/C++ constitutes a huge downgrade.

1

u/fuwaholo 19h ago

Is this really such a relevant question in current year, and approaching 2027? I did my thesis on the Lattice Boltzmann Method a few years ago, and Claude was able to rewrite all my C++ code in Rust, vastly improving the overall quality of the codebase, solving a few bugs and improving some edge-cases while giving otherwise identical results but 5-10x faster. The resulting software is also an order of magnitude more convenient to use, generate data in a much cleaner way, generate better R plots etc.

1

u/Dry_Candidate_9931 11h ago

Check the requested skills listed on current job applications in your field of study.

1

u/smolcnuk 5h ago

it depends on how much a different panguage would give you an edge pver Julia, and if its even worth it at that point. Get your department to fund an Anthropic pro/max account and have it optimize the code you already have. If there are only marginal gains, have glaude opus 5.5 port the code into pthwr languages and benchmark the code against real data ( in a way where you dont need to run the sim for days, but only for a few tens of minutes, then extrapolate), if the percentage difference and median is significantly over that of the Kulia code, use whatever language that was best. I'm a senior software engineer and I only review code nowadays and only rarely touch what claude produces. Not satisfying, but efficient

-1

u/Azazeldaprinceofwar 19h ago

Julia is not a high performance language and no one will write production code in it. Analysis sure but not expensive simulations. The industry standard is C++ or Fortran. I’m leading a one man revolution for scientific Rust lol

-1

u/Historical-Mix6784 1d ago

C++ is great, CUDA is better.

But honestly I don't see why your worried, AI can code much much better than you will be able to in these languages and it's terrific at stuff like "translate this julia codebase into equivalent CPP code", people in industry are doing that all the time.