holowoodman

No. Coding is mathematics. The internet exists because of engineering. The web was invented because of physics.

Humanities came late to the game and try to claim the honor without actually having done anything. Except whine and complain about the demise of X because of this new fangled internet thingy. For X you may insert "reading", "writing", "critical thinking", "books", "education", "manners", "discussions" and another 50 things at least. I'd say the humanities hindered the progress of humanity more than they promoted it over the last 50 years.

Because they want to have their cake and eat it too.

A fair pricing model would be token-based, so that a user can see for each query how much they cost, and only pay for what they actually used. But AI companies want a steady stream of income, and they want users to pay as much as possible, while using as little as possible. Therefore they ask for a monthly or even yearly price with an unknown number of tokens included, such that you will always pay more then with token-based payments.

The world isn't child-safe. Nobody would want children to play on a motorway, nobody would feed children xxxtra-hot curry of death, nobody would want children to drive a car or play with kitchen knifes.

Yet none of those far more problematic things comes with an age check, a fence, government controls or any special kinds of locks. We just educate children, and parents pay attention. Children that are too young to understand are put in special places like kindergarten, and even at a later age are often supervised by responsible adults.

I don't see why the internet should suddenly be all of that in reverse: Things like the online safety act require a whole world full of child-safe sites, and a child-impenetrable fence put around the few ones considered unsafe. This is totally ass-backwards.

For floor plans, there is Bonsai as a Blender addon. It is usable and does a lot of what you want (and tons more), if needed you can also script it with Python or create its native IFC format through Python libraries:

https://extensions.blender.org/add-ons/bonsai/

FreeCAD can also do 2D sketches and you can snap to angles, enter target lengths and skript it in Python. But even though it is older than Bonsai, it is harder to use (imho) and less stable (save often).

And if it is strictly about relatively simple floorplans, try sweethome3d. Slowish because it's java, and cannot do a whole lot, but enough for quick sketches.

Then pray tell, how come that the most parallel and most demanding computations like weather simulations, fluid dynamics and stuff like that avoid superior Java like the plague? Shouldn't it have been a blessing with its easier parallelizable code?

The reality is that it's quite the opposite. Java boxed types, lack of control over memory layouts leading to page flapping and false sharing, lack of fast synchronisation primitives, lack of a compiler capable of hinted or automatic loop parallelization lead to Java being totally unsuitable here. The crown goes to FORTRAN in that regard, with C and C++ being second and third places.

Of course theoretically a magic fairy-tale Java compiler could look at the code, recognize all the aforementioned problems and fix them. Of course the language would allow for this to happen totally without changing semantics. But no Java compiler even comes close...

The current context is compiler optimizations, as per the original article. That means we are talking about performance as a compiler produces it (or doesn't).

It sounds more formal than it should be. In my mind, it's more about easier searching and retracing steps and decisions. The only really formal thing in there is the list of TODOs and the DECISIONS. The first ones because obviously you need people to do them, and it's easier if they are automatically on a list of theirs and not forgotten. The DECISIONS are important because in retrospect somebody always will want to know the when/how/who/why around them.

But you could be right, this might not be the unifying tool for everything but more like number 29 that has never replace the previous 28...

In the most cases, you should imho skip the traffic lights all together and use a roundabout. Automatically balancing, can work to large capacities (not as large as traffic lights, but visit France if you need to see how much traffic they can handle). No fragile electronics, no power consumption, less maintenance, less accident-prone (really!).

Btw, question to the wisdom of HN: Good meetings need minutes.

Is there a minutes taking tool that does automatically list the attendants and their join/leave times, allow me to create items like TODO, DECISION, POLL, DISCUSS_MORE, GET_INFO, BLOCKER that will then be tabulated and cross-referenced automatically across more than one meeting? And added to the TODO-lists of participants referenced?

Preferrably somewhat independently of the conference tool in use, because that varies a lot around here.

Our company "good vibes" team, after some anonymous suggestions, managed to make this a company-wide policy. Every meeting room has a poster with rules to that effect, and managers are supposedly judged by adherence to those rules.

Not 100%, but seems to work.

> Brainstorming in a meeting is by far the least effective way. It just comes down to the most brazen flaunting their unnuanced opinions in rapid fire while more considerate and intricate reasoning is speed ran and drowned out by loud advocacy.

To fix that, the moderator needs to do what I would call "round-robin brainstorming". Each other participant has to have made exactly one point (in seating order or spontaneously) before the first one can make another one. Everyone has to weigh in, and at least for the first 2 or 3 rounds, the moderator needs to enforce this. Usually by then, everyone has warmed up to the idea that their ideas are not that stupid after all, and participation is more equalized.

Edit: about your other points: yes, I agree.

I guess they just want to collect movements of all their citizens, and this is their way to get at the data.

This is solving the wrong problem. If a traffic light can turn green at a whim, for any arriving app user, the intersection is not busy enough to have a traffic light. Then the traffic light should be removed or switched off for those times, instead of getting a very expensive (I presume) upgrade. If the intersection is busy enough so that people are waiting on all (or most) stop lines, then simpler traffic density sensors are a better, less invasive, far cheaper, and more privacy-preserving option.

> Maybe think about why Java is used extensively by pretty much every FAANG company.

Java programmers are a dime a dozen. Universities churn out heaps of Java code slaves, so of course every big company will use Java for their shovelware.

Ah, now the excuse for being slow is "tradeoff".

No big difference for stuff that waits for I/O, at least if it doesn't do it in an inefficient way. No Java in sight in the top lot for "Cached queries" which is the one where language makes a difference.

> As ever, hardware is an underappreciated factor. We have make-C-go-fast boxes today.

That is a very common misconception. There have been numerous attempts at architectures that cater to higher-level languages. Java-bytecode-interpreting CPUs have been tried and were slower than contemporary "normal" CPUs at executing bytecode. Phones and smartphones were a supposed hot market for those, didn't fly, native bytecode execution is dead nowadays. Object-orientation in CPUs has been tried, like in Intels iAPX432. Type-tagged pointers and typed memory has been tried. HLLCAs were all the rage for some time ( https://en.wikipedia.org/wiki/High-level_language_computer_a... ). Early CISC CPUs had linked lists as a fundamental data type. Lisp machines did a ton of stuff in hardware, GC, types, tagging, polymorphism. All of it didn't work out, more primitive hardware with more complex interpreters and compilers always won. Not because C was all the rage at the time, but because high-level features in hardware are slow and inflexible.

What came of it was the realization that a CPU must be fast and flexible, not featureful. That's why we got RISC. That's why CISC processors like x86 internally translate down to RISC-like microcode. The only thing that added a little more complexity were SIMD and streaming architectures, but only in the sense that you could do more of the same in parallel. Not that HLL constructs were directly implemented into a CPU.

Granted, malloc/free isn't totally free. But malloc/free languages always seem to be faster than Java in benchmarks, at least the ones I've read and referenced already in the comments around this article. GC also, even if it were faster, comes at the expense of eating RAM like mad, at least if judged by the RAM Java likes to eat. Usually, Java software just consumes 50% of your RAM until the first GC pause. And even before that GC pause, it's dog slow.

Memory fragmentation can more easily be reduced by pooled allocators. For long-running server processes, it can also be possible to just kill the worker processes/threads from time to time. And I've never seen memory fragmentation in manually allocated languages lead to more memory consumption or worse performance than in Java.

I'm saying that Golang is one of the worst-performing compiled languages, and even Golang is faster than Java for the respectively fastest program on the page I've referenced. Other compiled languages are even better than Golang.

Problem is that those constraints are often very hard to express, even in more expressive languages.

One example would be integers. There are bigint-by-default languages like Haskell, where the type you usually use is an arbitrary-sized bigint. But usually you don't need that, and you usually know that something like a 32bit integer is sufficient. Often you get a int32 type that does that stuff for you. But then the question becomes about overflow behaviour, signedness, existence of -0, behaviour of -INT_MAX and stuff like that. Even in C, you are in undefined-behaviour-launch-the-rockets territory very quickly. And there are usually no "screw it, I don't care, give me whatever the CPU does" types. You don't get to choose your overflow/underflow behaviour. Often no bounded types either (unsigned integer day from 1 to 365). And if those types are available in libraries, the compiler won't be able to optimize.

There are tons more of those examples. It's always a compromise between the expressiveness that we want and that would be great, and the complexity that will make an implementation non-viable. So you get as much expressivenes as the language designer thinks he could maybe cram into his compiler. But it's always to much to be really optimized all the way through. And it's always too little for what one would actually need to be really exact.

If you look at the extremes, it is up to a factor of 3: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

If you exclude stuff like SSE intrinics, it's usually 50% slower.

Yes, you are right. I think they are head-to-head nowadays.

I was thinking about, and meaning to post that one, but got the wrong search result:

https://www.phoronix.com/review/clang20-gcc15-amd-znver5/5

But they swapped places a few times over the last years, so basically there doesn't seem to be a fundamental difference in performance anymore.

The grandparent made specific claims about scenarios where Java is supposedly faster:

> Yes, Java can be faster in certain contexts: the kind of contexts Java is usually employed in addressing these days. Stuff like enterprise backend systems and big data processing, where startup time or precise memory control are not important.

The only thing that might be relevant in your list is the vectorization API.

The rest of your list is just a bunch of band-aids for the worst problems that Java specifically has, that other languages lack. That is at best playing catch-up with everything else, since in C there is no GC overhead, almost no startup time, no object overhead, no GC-induced memory hogging, no GC pauses. Yes, I agree that things did happen. But nothing in there makes Java any more desirable for relevant workloads, it just makes it less undesirable.

That is garbage collection performance, something that only GC languages even have to consider as additional overhead. It also doesn't even try to compare against anything non-Java.

There are no serious Java performance comparisons on stuff like transaction throughput, which would be what the "long running server application" usecase should aim for. You yourself claimed that enterprise data processing is what you are talking about. There are benchmarks that even with long warmup times make Java come up far worse than all the compiled languages (even Golang nowadays). https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Imho, people have stopped benchmarking Java ages ago, since it is known to be hopeless.

No. First that isn't SIMD code. Second, CMP r0,0 is redundant, operating on a register that is zero will set the zero flag automatically. You also skipped the string search/comparison part, but that isn't relevant, except that the operation will implicitly set the zero flag. Generally, plain JZ is faster than CMP + JZ. Even more so if it is SIMD.

And loads are amortized by tons of speculative preloading. Which isn't (yet, unfortunately) optimized by preload-length hints.

Oh, and since we are talking about comparing strings, there is no extra load. This isn't strlen(), this is strchr() or strstr() we are talking about. You always have to load the string into some register.

I'd like to see those numbers please. While there have been improvements, Java performance work seems to have stopped after 2011 or so. Mobile CPUs became fast enough for Android, so no movement there. And commercial software got stuck on numerous proprietary Java VMs that didn't improve after the Oracle takeover of SUN. Alterative VMs improved, but didn't get adopted, fragemented and in the end didn't really raise the bar a lot.

To this day, Java applications are the slowest and most memory hungry long-running server applications by far. Only some scripting languages are worse, but only by performance, almost never by memory.

>> LLVM is still slower than GCC, even in plain C.

> Citation needed. Last time I checked LLVM beat GCC on -O3.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://www.phoronix.com/review/gcc-clang-eoy2023/8

There is tons more, just ask your favourite internet search engine.

> Why should two nearly idenfical operations have such wildly different performance? And why isn't the safer/saner interface more performant?

Because in hardware, checking a zero-flag on a register is very cheap. Big NAND over all bits of a sub-register, big OR over all those flags for the whole SIMD register. Very short path, very few transistors.

Checking a length is expensive: Increment a length register through addition, including a carry, which is a long path. Compare with another register to out if you are at the last iteration. Compare usually is also expensive since it is subtract with carry internally, even though you could get away with xor + zero flag. But you can't get around the length register addition.

There can be an optimisation because you do have to increment the address you fetch from in any case. But in most modern CPUs, that happens in special pointer registers internally, if you do additional arithmetics on those it'll be expensive again. x86 actually has more complex addressing modes that handle those, but compilers never really used them, so those were dropped for SIMD.

Then were is my easy Haskell tooling to find the place where I should put a strictness hint? Where is the equivalent of kcachegrind?

That it's supposedly easier might be true. But that usually doesn't lead to someone really doing it.

There were tons of people making those claims. https://stackoverflow.com/questions/64582/c-java-performance...

Especially profile-guided-optimization was hailed as the next big thing, only JIT-ed languages were the ones to be fast, because after some warmup time they would adapt to your data and hardware. Java is still dog-slow...

And here we go again with the compiler excuses.

C standards with the 'restrict' keyword to allow aliasing optimisations have been existing longer than Rust. LLVM just never bothered, despite the early claims that all the intermediate language and "more modern" compiler would enable more optimisation potential. LLVM is still slower than GCC, even in plain C.

Where is the problem to quickly null-terminate a pointer+len string and use the quick null-terminated SIMD search? Should only be 1 move slower than the native C. "Space after that string" shouldn't be a problem, since in higher-level languages, allocations can make enough room, it is higher-level after all (and you need null-termination for syscalls anyways).

It is always the same story. Compiler and programming language people make claims about future optimisations but never ever follow through. It's always just theory, never implementation.