hpcjoe

Working with a variety of AI models (Claude, Grok Build, various locally run models) and agents, I am scratching an itch.

When people deploy python and perl code, they have to either export their entire environment, or build a container. The latter is not possible in a number of deployment cases, and the former carries all manner of dependency radius gotchas.

So I am building (ok, I am prompting/testing/reviewing, the agent is doing the heavy lift) compilers for each of python 3.14.x [1] right now, and perl 5.42.x [2], that can generate static code.

Early stages, perlc does work well, pyc is a work in progress.

[1] https://github.com/joelandman/pyc

[2] https://github.com/joelandman/perlc

Look for llmfit on github. This will help with that analysis. I've found it reasonably accurate. If you have Ollama already installed, it can download the relevant models directly.

Thoughts on disabling ad blockers, subscription requests for sites, and the economic model underlying much of the internet these days.

Teams regularly fails at video conferencing. It complains of low network bandwidth at random times, and I check my firewall (OpnSense with fq_codel enabled and reasonable bandwidth limits) to note that it under very light load.

I am not sure if this is a server side thing at Microsoft, or a problem with the application itself. True under Windows, Linux, via local app, and via the web app.

For larger meetings (> 50 people), we use zoom. Unlike teams, zoom generally just works. Quite well in fact.

Teams is simply crap software, forced upon us. If we could jettison that and Outlook, I would be grateful. Though our IT looks at us in an unblinking stare, if we ask them to allow us to use any of the better clients on mobile, laptop, desktop, windows or linux. Its almost as if our third eye in the middle of our forehead opened up.

I noticed the comments pointing out that TDP is a marketing number, and max power draw for this part can be higher. The cooling seems to have been inadequate.

A rule of thumb I use for cooling is, you can rarely have too much. You should over-engineer that aspect of your systems. That and the power supply.

I have a 7950x, with a water block capable of sinking up to 300W. Under heavy load, I hear the radiator fans spinning up, and I see the cpu temp hover around 90-93 C. That is ok, though cooler would be better. My next build (this one is 2 years old) will also use a water block, but with a higher flow rate, and a better radiator system. I like silent systems, though I don't like the magic smoke being released from components.

As will Python and many others.

I recall that while I was at SGI. Many of us within SGI were strongly against the move to sell this off to Sun. We blamed Bo Ewald for the disaster to SGI that this was, the lack of strategic vision on his part. We also blamed the idiots in SGI management for thinking that only MIPS and Irix would be what we would be delivering.

Years later, Ewald and others had a hand in destroying the Beast and Alien CPUs in favor of the good ship Itanic (for reasons).

IMO, Ewald went from company to company, leaving behind a strategic ruin or failure. Cray to SGI to Linux Networx to ...

Same in Julia, but no need to "import math", its already built in :D

    joe@zap:~ $ julia
                   _
       _       _ _(_)_     |  Documentation: https://docs.julialang.org    
      (_)     | (_) (_)    |
       _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
      | | | | | | |/ _` |  |
      | | |_| | | | (_| |  |  Version 1.10.5 (2024-08-27)
     _/ |\__'_|_|_|\__'_|  |
    |__/                   |

    julia> z=1+2*im
    1 + 2im

    julia> z*conj(z)
    5 + 0im

    julia> sqrt(z*conj(z))
    2.23606797749979 + 0.0im

    julia> abs(z)
    2.23606797749979

Not true by any stretch. I've used komodo[1] for more than 2 decades as a debugger in Linux, Mac, and Windows. More recently VSCode on all 3, for debugging.

Definitely not a dead language. A mature and stable language, which won't surprise you.

[1] https://www.activestate.com/products/komodo-ide/

I have perl code I wrote in 1992 that still works properly, without changes. The binary executables have changed ISA from MIPS 4 to x86_64, and are compiled fortran (gfortran). There's even a switch I use to be able to read the large endian binary files in gfortran.

My c code from 1996 requires rework. My C++ code from 2014 requires rework (I had to do this with others code as well to use a std capability). Python code rarely survives 3.6 -> 3.12 never mind 2.7 to 3.x. I worked at a company that had (very unwisely) written a massive part of its infrastructure in Py2.7, and was using it a decade past its expiration date.

Perl just works.

At a previous job, I regularly worked with dfs of millions to hundreds of millions of rows, and many columns. It was not uncommon for the objects I was working with to use 100+ GB ram. I coded initially in Python, but moved to Julia when the performance issues became to painful (10+ minute operations in Python that took < 10s in Julia).

DataFrames.jl, DataFramesMeta.jl, and the rest of the ecosystem are outstanding. Very similar to pandas, and much ... much faster. If you are dealing with small (obviously subjective as to the definition of small) dfs of around 1000-10000 rows, sticking with pandas and python is fine. If you are dealing with large amounts of real world time series data, with missing values, with a need for data cleanup as well as analytics, it is very hard to beat Julia.

FWIW, I'm amazed by DuckDB, and have played with it. The DuckDB Julia connector gives you the best of both worlds. I don't need DuckDB at the moment (though I can see this changing), and use Julia for my large scale analytics. Python's regex support is fairly crappy, so my data extraction is done using Perl. Python is left for small scripts that don't need to process lots of information, and can fit within a single terminal window (due to its semantic space handicap).

A friend sent me the image from page 9. The email signature. It is mine, from when I ran my company. Mid 2010s.

I'm not much worried about this specific example of information exfiltration, though I have significant concerns over how one may debug something like this for applications working with potentially more sensitive data than email signatures. Put another way, I think we are well within the infancy of this technology, and there is far more work needed before we have actually useful applications that have a concept of information security relative to their training data sets.

1: Yes. Has happened 3 times in my career, most recently this past May.

2: Minimally. I was asked for the reason for my departure, and I was transparent as I could be, indicating what I knew and the circumstances. People were curious about it, but then again, its not relevant to finding new work. I will say that I found that multiple potential employers concluded successful interviews with unrelated programming tests. It felt like a set of coffin problems[1], that older folks like me, not trained in CS, but writing code for 40+ years, would not do well on.

This is a huge red flag. I actually had someone tell me that I 'needed to know how to program' to do the job I'd applied for, even though I have a public documented history of programming and software development/engineering, have developed and shipped code for decades, for research, products, patches, ...

That impacted search a bit.

3: There's not much of a stigma these days. Your self worth is not tied up in your job. Your value isn't either. You can take time to decompress, retool, think, train, research.

Put another way, if an employer thinks its a problem, you might want to steer clear of that employer. Bring the conversation quickly to a close, amicably, so you don't waste time and create bad feelings.

On jobs in general, employers generally are their to please and profit their owners. Understanding all their actions in terms of this (HR is there to protect the employer, etc.) can help you separate your sense of self worth from the position or company.

[1] https://www.reddit.com/r/math/comments/gxpoyo/soviet_coffin_...

This is my current pain with Julia. It makes deploying code require the entire environment, or a PackageCompiler built sys-image. I've played with static compiler, and other techniques. They are sadly quite brittle for my previous use cases. Lack of ability to use threads in a static compiler built binary was a deal killer for me.

FWIW, I've used MaraDNS for a while, about 10 years. It works nicely for my small domains. It is missing some things that require I do some workarounds, but for the most part, it does what it says on the wrapper. Its not hard to configure, no messing around with multiple/many backends and backend configuration. Just simple db files, easy to keep in git, easy to deploy, easy to manage and change.

If you are running a large SaaS this might not be the right package for you. But if you are putting together a small site (blog, single page webapp, etc.) this is a great, simple, and easy to deploy tool.

the "winning" strategy is to have high-level scripting languages where you can ignore most of the details, which call into hyper-optimized, high performance libraries. For instance, when you're using Scipy, you call into Fortran and C almost interchangeably.

Well, no. This is python's strategy. Doesn't make it the winning strategy. Python implicitly forces multiple languages upon you. A scripting one, and a performance one. Meanwhile languages such as Julia, Rust, etc. allow you to do the work in a single (fast/compiled) language. Much lower cognitive load, especially if you have multiple cores/machines to run on.

Another point I've been making for 30+ years in HPC, is that data motion is hard. Not simply between machines, but between process spaces. Take large slightly complex data structures in a fast compiled language, and move them back and forth to a scripting front end. This is hard as each language has their own specific memory layout for the structures, and impedance matching between them means you have to make trade-offs. These trade-offs often result in surprising issues as you scale up data structure size. Which is one of the reasons that only the simplest of structures (vectors/arrays) are implemented in a cross language scenario.

Moreover, these cross language boundaries implicitly prevent deeper optimization. Which leads to development of rather different scenarios for code development, including orthogonal not-quite-python based things (Triton, numba, etc.).

Fortran is a great language, and as one of the comments pointed out, its really not that hard to learn/use. The rumors of its demise are greatly exaggerated. And I note with some amusement, that they've been going on since I've been in graduate school some 30-35 years ago. Yet people keep using it.

So I pulled up my jpg of the Sombrero galaxy to see (its been my laptop background for a few years). I could barely make out Iris in it. Absolutely awesome though!

Something about the deep field and ultra deep field pictures that makes me happy. Also makes me wonder about how many beings in these other galaxies look out, see Milky Way colliding ever so slowly with Andromeda in their own deep field views.

Ugh ... that's depressing.

I just went through this process. Got autorejected after the personality/IQ test thing. My essay was 13 pages.

As for notable things I've done, I worked on an experiment in undergrad, which won the PI (small group) the Nobel in physics in the late 90s, writing computer software for experiment control. That and getting a PhD in physics from a student of a student of a different Nobel laureate. I founded and ran my own company for about 14 years getting to millions in revenue with no external initial investment. I worked with my business partner to try to raise money to build accelerators for computing in 2002-2007 as I'd argued that they would be the dominant form of HPC in the mid 2010s. No investor would bite.

But sure. Ask me about high school. Not the 40 years since high school.

Canonical is a complete waste of time/effort. Ubuntu is a fine distro, but the hiring process is so completely flawed, as this article and many others (check out glassdoor, my interview is now up as well)

That someone (likely very senior) greenlit this process, signed off on it, and thinks it is successful enough to keep doing it, is a massive set of red flags about this company. The company reviews (not interviews) on glassdoor tell me the same story. Its like their employees have written a collective "WTF", and management is completely impervious, blissfully clueless, as to how broken, how disfunctional, their processes are. The implicit assumption in this is that if they were aware, they would adapt and change them. I do not believe this to be the case.

So, in summary, steer a wide path around this company. You don't need their crap. Maybe, eventually, they will get a clue. Though I think this would only happen when there is a materiel leadership change at the top.

Catastrophic loss of precision is, as the name implies, catastrophic in terms of the calculation context. For scientific/engineering codes, and things requiring a preservation of resolution for proper functioning, FP32 is rarely sufficient. FP64 is usually better. For ML/AI apps, resolution isn't nearly as important.

Location: Ann Arbor, Michigan, USA

About: PhD theoretical and computational physicist writing code, working on modeling systems, teasing actionable data out of massive (TB->PB) data stores, building very high performance applications, systems. 25+ yoe in a professional capacity. I work with clusters, supercomputers (I like the heavy metal :D ), clouds, etc. I've been an IC, CEO/CTO, manager, director. Looking for a fun place with hard (mathy/computey) problems.

Remote: preferred, or hybrid

Willing to relocate: yes to NYC area, Austin Tx, Chicago area

Technologies: High Performance Computing (HPC) focus

  - parallel/vector code (OpenMP, MPI, threads, AVX primitives, some CUDA and ROCm, ...

  - performance measurement and application tuning/optimization: perf tooling, eBPF, prof/gprof, ...

  - storage system design, implementation, management: Lustre, NFS, BeeGFS, Minio

  - distributed resource managers: Grid Engine, SLURM, LSF, ...

  - optimized toolchain builds: Python, Julia, Perl, ...

  - HPC environments and languages: Python with Numpy/Pandas/Polars/..., Julia, Fortran (yes, it is still used), C/C++, Octave/Matlab, gnuplot, Maxima, ...

github: https://github.com/joelandman

email: hnjl@scalability.org or via linkedin

I don't support this at all. This is printing as a service, with interesting consequences once you cancel the service even with remaining assets available to you.

To get you to think about this some more, apply this to computing and storage as a service.

The gotcha risk is far ... far higher than you think.

Caveat cloud/aaS emptor.

Back in my more perl-ish days, I recall pythonistas doing this. Sad to see little has changed.

Julia is very fragmented

No, it isn't. I'm using Pandas, DF.jl, and even polars at work. DF.jl is by far the best/easiest/quickest to use, as its syntax is consistent. Polars is a bit more annoying as its syntax is further along the learning curve that I have gotten yet.

Pandas ... what to say about a library that will happily return a pd.Series in one moment, and a pd.DataFrame in another, for the same function call. This means you need extra code like

if type(ret_thing) = pd.Series: # then do something to coax it back to a df.

lest your actual code break.

This is of course the same language that has API differences that make no sense in, say, re.match vs re.findall vs re.search. I've been burned by all of those.

So, look, we get you hate Julia. That's fine. Go live your python life to its best. But really, stop with the misinformation/FUD. This speaks volumes about you, and tends to make the case precisely the opposite of what you think.

And yes, I use Python, Julia, C++, and many other languages in the $day_job.

I've been looking into that for a while, as a way to create a common environment for users in my team. I did get it to work, though as you mention, build times are long for this.

If funding's a problem across many fields then wouldn't it perhaps make better sense to just accept Fortran as the most appropriate language for certain well defined application types/fields and concentrate on improving the language, that is fixing its actual or perceived limitations in current environments?

Yes it would. It would make far more sense than writing whitepapers extolling the risks of staying with the language, for example.

It would seem more efficient to centralize effort to improving just the language and its tools than to convert or rewrite a whole world of disparate applications that have been developed over many decades.

There are ISO committees dedicated to improving Fortran[1].

...

It seems to me that rationalizing and simplifying the language problem ought to be a high priority for CS.

It is not. This would relegate CS to a different role at a university, more of a tool building and improvement (e.g. engineering) than a "science". Moreover, there is no real money to be made, or reputation to be created by improving a tool. Especially one that has been in use so long.

CS loves to follow/lead with the new shiny thing. This is how the profs get grants. Show their value to the community. Get their students hired and starting companies. Or taking a leave from university, and going to work as chief scientist of AI at large global companies. (cough cough)

Most of these researchers would prefer to show their value and the value of their thoughts/work, by creating new and shiny things in languages or new languages. Yes, this is cynical. I've seen it first hand. I've watched fads/trends wax and wane in CS for a while now. Often times being unaware that much work was being repeated.

[1] https://j3-fortran.org/

It is possible, within specific limits, using StaticTools.jl and StaticCompiler.jl. Sadly for me, my code won't work within the indicated limits.

This is the biggest issue for me, for deployable code. I'd love to hand my users a single binary (like go/rust), which has all the code/data needed, so no precompilation time, and instant startup. I am hoping the Julia team understand how important this is ... language competitors have runtimes (python, etc.) or binaries (go/rust/c++). We really need the latter to distribute code to production.

Imagine a post compilation step, kind of like the code caching, which wraps everything we need into a binary, with compiled cached code, startup code, runtime libs, etc. . That would be amazing, and fit well within the julia paradigm.

My packages at work are about 1.5k lines. Precompilation is about 10-15 seconds. After precomp, about 1-2 seconds to load with "import" or "using". The longest I've seen on precomp have been DifferentialEquations.jl. I've not used it in a while, though I have plans to for personal (non-work related) projects.

My packages have 5-10 dependencies in them, I tend to keep my packages/tooling streamlined, and I performance optimize them (everything from loading time, through data structure/algorithm implementation) quite thoroughly.

Other users at my firm are adopting Julia as well. It isn't displacing python, though that is a possible future. Its similar enough that many grasp it right away. Its fast enough that its a viable alternative to Python + C++.

This said, Julia is not a silver bullet[1], though it is an excellent programming language. It has been able to do all of the same tasks as my python code. Faster (often multiple orders of magnitude) working with 10s to 100s of GB of data, in parallel.

Its a better solution for my workflow, and an increasing number of others. If its not to your liking, that's fine. No need to try to push it down with, from my vantage point, what seems like specious claims (very long precompilation times close to an hour, or so). If you have such actual examples, please post them. I'd love to see them. Chances are we could optimize this fairly easily.

[1] https://www.merriam-webster.com/dictionary/silver%20bullet

Fortran was old in the early 1980s, when I first taught it to myself for use on a research project. I'd taught myself BASIC, x86 assembler, and APL (for another physics course) by then. All the serious physicists were using Fortran though, for all their simulations.

My research project required use of the university mainframe for the big calculations, the 1000x1000 Markov matrices I was working on. I taught myself how to work on out-of-core code then as well, as well as exploiting symmetries inherent in my models.

My Ph.D. code was all written in Fortran, with a little Perl thrown in for good luck. 30+ years later, all of it works without a problem on my laptop/desktop machines.

I learned C in 1996 and C++ in 1997. The C code I wrote still works, though the C++ code needs special compilation options to be able to work.

I've not used Fortran in maybe 15 years now. I'm not up on the modern bits, I stopped using it professionally as F90 was becoming a thing.

I taught graduate HPC programming courses at my alma mater in the CS department, and gave the choice of Fortran or C to the kids. They blanched at the thought of using a nearly (at the time) 60 year old language. They correctly reasoned that learning the language would not help their employability.

Today, I use Julia for heavy computation. Python as a glue language, and C++ when required. I read the report, and I disagreed with the conclusions for a number of reasons, but what it comes down to is that many research groups in Physics/Chem still use Fortran, and aren't about to do the port to C/C++ due to funding. You can't get funding for this conversion. So codes will go on, students will learn what they need, and profs will keep publishing papers.

Moreover, this isn't the first, second, etc. time that people have predicted the death of Fortran. I heard this in 1990s as I was finishing up my Ph.D in theoretical/computational physics.

In 20 years or so, after I have (hopefully) retired, I'd bet that Fortran is still in widespread use, with Python following Java down the path to legacy. And the newer HPC language(s) will be quite happy to talk to Fortran.

I could be wrong, and I'm ok with it. But I doubt it.

There's an old joke in math/physics student circles that covers this.

Student goes to see the prof in their office hours to try to understand something the prof said is seen to be trivial. They spend 4 hours working on it, and the student returns to their friends in class. They ask how it went. The student says "yeah, it was trivial."

For those who don't quite get the joke, 4 hours to show something is trivial, tends to not support that the thing is trivial to comprehend.