HackerTrans
TopNewTrendsCommentsPastAskShowJobs

m_mueller

no profile record

Submissions

Yes, Europe's heat waves are deadlier than American gun violence

fortune.com
18 points·by m_mueller·14 gün önce·9 comments

Why $207M in AI Spend Hasn't Fixed Corporate Slide Decks

octigen.com
6 points·by m_mueller·2 ay önce·0 comments

Why $207M in AI Spend Hasn't Fixed Corporate Slide Decks

octigen.com
4 points·by m_mueller·2 ay önce·0 comments

Are You Managing Your AI, or Is Your AI Managing You?

octigen.com
1 points·by m_mueller·3 ay önce·0 comments

Are You Managing Your AI, or Is Your AI Managing You?

octigen.com
3 points·by m_mueller·3 ay önce·0 comments

Copilot for PowerPoint: Reasons It Fails

octigen.com
5 points·by m_mueller·3 ay önce·0 comments

Beyond the Big Three: Building a Sovereign EU Cloud Stack

octigen.com
6 points·by m_mueller·4 ay önce·0 comments

A Swiss Paperwork Massacre: Why We Fled to Stripe

octigen.com
6 points·by m_mueller·4 ay önce·0 comments

comments

m_mueller
·13 gün önce·discuss
and that's exactly the point: regulations absolutely need to change, just like gun laws in the US.
m_mueller
·13 gün önce·discuss
a) most people where I live are renters. property prices make it so.

b) in many if not most places (in Northern Europe), AC requires a permit, is very hard to get approved or even forbidden.
m_mueller
·14 gün önce·discuss
That last point for me is crucial. That's why the comparison IMO holds - a mostly preventable cause of death, ignored for political reasons.
m_mueller
·geçen ay·discuss
Cost is one thing, time is another. You’d need massive investment in trade education and then wait 20 years. See vocational education in German speaking countries as an example.
m_mueller
·2 ay önce·discuss
I keep looking around and not finding any, so let me just try here before someone just takes it and slopifies it:

* built-in multidimensional arrays with efficient storage.

* related to this: built-in array intrinsics

```

real, dimension(100,100) :: A, B, C

C = A + B

```

this kind of code is already a close-to optimal "naive" implementation (not considering parallelization). so you start already at a solid place. then you can easily run it in parallel without too much specialized knowledge with OpenMP, OpenACC, MPI or even CUDA. the only thing you really need to be aware of when implementing your own loops/kernels: the intrinsic storage order, to optimize for cache hits.

* crucial: all the above amounts to a standard/best practice about how data is structured and formatted. everyone just uses the built-ins. Thus, interoperability between native Fortran numerical libraries is usually a complete non-issue. Meanwhile, Cpp has a fractured ecosystem with different array/vector types for its libraries. Converting between one and the other is usually a no-go.

* next, the intent plus pass-by-reference system. it combines IMO the best of both worlds of a functional vs. procedural approach:

  - I can predefine if an array / variable is intended as input, output or both, simply with `intent(in)`, `intent(out)` etc.

  - compiler can thus do checks for me if I'm breaking a contract.

  - yet, since I pass by ref, I don't have to worry about memory not being used efficiently. This really matters once you deal with GB, TB or even PB worth of data going into a simulation over time - there's just no way to deal with that in a purely functional way.

  - only where really necessary, you can still drop down to pointer semantics, e.g. for the outer glue code of a simulation that swaps outputs and inputs for the next time step.

  - having `restrict`-by-default semantics here helps immensely. Imagine you have many arrays with lots of data to deal with, and your kernels access always several at a time to do calculations. In Fortran I can write it intuitively, while in C/C++ I must remember to specify `restrict` or to preload all point-inputs first into separate variables to direct the compiler. Otherwise the memory pressure increases, and by far most such physics simulations are memory bandwidth bound - every access counts.
* finally, a clean symbol definition system that decouples types from byte lengths. a `float` in fortran is just `real(4)`, a double is `real(8)`, a long int is `integer(8)` and so on. now, it's trivial to do a bit of preprocessing to switch the precision.

However, the last part is where Cpp has a strong advantage: Well supported meta-programming (generics, templating or even just well supported pre-processors). Fortran's compilers come with a lot of built-ins, so the lack of these is less of an issue than you might think, but it's still a limiting factor. All that being said, a typical scientist doesn't tend to care and just wants to solve a particular problem rather than thinking in generalized frameworks - and that's why I find Fortran still serves them better for numerics than anything that came since.
m_mueller
·2 ay önce·discuss
I take it you probably never tried to use any of these languages for HPC. Without a language standard, you have two options there to compile decently performant executables: (1) compiler pragmas, (2) give up and drop to assembly code.

I should add here that there's also (3): Switch to Fortran, which made fundamentally different choices and is IMO the only fully supported higher-than-C level language that can produce HPC applications without fighting a compiler left and right.
m_mueller
·2 ay önce·discuss
It's a bit confusing to me why they'd make this 'fast' version the default, as it appears to be much more expensive than Composer 2. Wasn't it supposed to be a very cheap alternative to SOTA models?
m_mueller
·2 ay önce·discuss
Tangential, but in our opinion corporate PPTX automation is an unsolved problem, even with Claude for PowerPoint (and it's worse with everything else common out there). Its harness (a) is not tuned very well for corporate use and (b) even if it were, fails to manage the specific business knowledge within each org needed to create effective (i.e. audience tailored) presentations.

I've just written a blog post about this topic this week: https://octigen.com/blog/posts/2026-05-11-ai-presentation-ga...
m_mueller
·2 ay önce·discuss
Also, Airbus is doing very well last I checked.
m_mueller
·2 ay önce·discuss
here I think it's less about "poverty" (non-US acedemic budgets are still high, though not in the same sphere), but it's about having red tape when it comes to software. My experience doing a PhD in Japan was: Everything you can touch was basically a free for all - including $500 keyboards and $10k Mac Pros, especially if you are a valued researcher. But software, oh man, how can we prove receipt of goods to accounting...
m_mueller
·3 ay önce·discuss
To me it just boils down to using the right tool for each job. I definitely wouldn’t use Fortran for anything heavily using strings. One weakness is also the lack of meta programming support. But for numerical code to be run on a specific hardware, including GPU, it’s pretty close to perfect, especially also since NVIDIA invested into it.
m_mueller
·3 ay önce·discuss
So that's where the intent system comes in (an argument can be in/out/inout) as well as the built-in array sizes, because it allows you to express what you want and then the compiler will enforce it. In Fortran you kinda have to work hard to invade the memory of one array from another, as they are allocated as distinct memory regions with their own space from the beginning. Pointer math is almost never necessary. Because there is built-in support for multidim arrays and array lengths, arrays are internally anyways built as flat memory regions, the same way you'd do it in C-arrays for good performance (i.e. cache locality), but with simple indices to address them. This then makes it unnecessary to treat memory as aliased by default.

Honestly, I still don't get why people have built up all these complex numerics frameworks in C and C++. Just use Fortran - it's built for exactly this usecase, and scientists will still be able to read your code without a CS degree. In fact, they'll probably be the ones writing it in the first place.
m_mueller
·3 ay önce·discuss
e.g. the climate models that could be run on some of these systems would dwarve anything we’ve been able to do so far.
m_mueller
·3 ay önce·discuss
btw. Fortran is implicitly behaving as "restrict" by default, which makes sense together with its intuitive "intent" system for function/subroutine arguments. This is one of the biggest reasons why it's still so popular in HPC - scientists can pretty much just write down their equations, follow a few simple rules (e.g. on storage order) and out comes fairly performant machine code. Doing the same (a 'naive' first implementation) in C or C++ usually leads to something severely degraded compared to the theoretical limits of a given algorithm on given hardware.
m_mueller
·3 ay önce·discuss
I think it depends on how strong the compression advancements are going to be, such that much can be done locally in the future. I'd be interested in experiences of others here in using Gemma4, which is at the forefront of "intelligence per gigabyte" atm. (according to benches).
m_mueller
·3 ay önce·discuss
"this so called planet killer doesn't matter to us, and we live in a free speech country! checkmate scientists"

like that?
m_mueller
·3 ay önce·discuss
so you want us to reed furst? wat ar u dumb?
m_mueller
·3 ay önce·discuss
imagine how it would hit today. I'd guess a vast majority would feel insulted by it...
m_mueller
·3 ay önce·discuss
~100 million consumers (assuming average sized states are impacted) being essentially defrauded by a cartel of telcos - doesn't really matter what you wanna call it but I'd say it's a pretty major deal.
m_mueller
·3 ay önce·discuss
I'd say first of all you need to put a lid on it, call this kind of thing again what it is (bribery), and make it illegal. Secondly, if someone wants a public office: pay them well (they'll still have the revolving door afterwards anyways), but all their finances will need to be published on a quarterly basis. It's not exactly rocket science, this kind of thing is implemented in many jurisdictions.