bluescarni

I am not really seeing how the first chart can be construed as AI disrupting the junior job market...

The 22-25 red line had plateaued before the release of ChatGPT and was already trending downwards by the time ChatGPT appeared.

Additionally, it took a quite a while before vibe and agentic coding appeared and gained traction, and I cannot really see how the precipitous decline between say Jan 2023 and Jan 2024 can be attributed mainly to AI.

The "other" reasons mentioned later in the post seem much more convincing.

Thusly, what happens in code that accesses the string after the move is UB.

No, it is implementation-defined behaviour.

In the implementation of C++ the article uses the string was just empty. But for all we know it may still contain a 1:1 copy of the original or 20 copies or a gobbledygook of bytes.

Yes, and if you want to make sure that the string is empty before you do something else with it, you just use a clear() (which will be optimised away by the compiler anyway).

Or, if you prefer, you can assign another string to it, or anything else really.

Any code that relies on the string being something (even empty) may behave different if it isn't. That's the very definition of UB.

No it is not.

"A typical implementation strategy" is meaningless for someone writing code against a language specification.

Then don't rely on that specific implementation detail and make sure that the string is in the state you want or, even better, don't touch the moved-from string ever again.

So apparently, move does not prevent generation of a copy, but the empty string instead of expected text “Dave” is very interesting. Apparently, after termination of show after the move, the object is invalidated. This does not affect the Person object, but only the string object. Recognize that I speak about a factual behavior on the hardware. I think we have undefined behavior here. And no compilation error.

There is a lot of wrong in this paragraph:

- a "copy" was not generated, at least not in the sense that the actual content of the string was copied anywhere;

- there's no undefined behaviour here and no invalidation of the string. Standard library types are required to be left in an unspecified but valid state after move. "Valid" here means that you can go on and inspect the state of the string after move, so you can query whether it is empty or not, count the number of characters, etc. etc. "Unspecified" means that the implementation gets to decide what is the status of the string after move. For long enough strings, typical implementation strategy is to set the moved-from string in an empty state.

As if typical HN comments were any better than typical reddit comments...

Most FSD buyers seem aware they’re paying into a research effort.

Shades of Star Citizen right there.

"Hacker" news, ladies and gentlemen.

It's eerily reminiscent of the x86 bashing that was going on in the early 2000s, only that in those days PPC was seen as the superior (new, baggage-free) ISA by Apple fanboys.

Then Apple switched to x86, and from day to night we witnessed the magnificent spectacle of the entire Apple fanbase performing a whiplash-inducing collective pirouette towards the narrative that, after all, x86 was not so bad.

My initial comment was correcting a factually inaccurate statement regarding CPU performance.

It is you who barged into the thread with unrelated GPU performance numbers, but whatever :)

Those are Tensor flops, the numbers for the Zen CPU are "general-purpose" flops (sometimes called "vector flops" in marketing material).

The vector flops for the 3090Ti are 33 TFlops for single precision, 0.5 TFlops for double precision. So, 16x faster than the 5950x in single precision, 2x slower for double precision. At almost 3x the price and >4x the power consumption.

Of course, if all you care about is AI, then there's no argument - but then we are not really talking about a general-purpose device any more.

The narrative of GPUs being "hundreds of time" faster than CPUs is vastly blown out of proportion for general-purpose computing.

Go and measure it yourself, if you have one :)

https://github.com/Mysticial/Flops/

You can also get a theoretical computation of the Flops, which matches nicely with the experimental measurement. You have to take into account:

- the clock frequency (~3.9 GHz on multithreaded workloads on my machine)

- the number of cores (16)

- the reciprocal throughput of the FMA instruction (~.5, that is, 2 instructions per clock cycle)

- the number of flops per instruction (2 for the FMA instruction, that is, 1 multiply + 1 add)

- the SIMD vector width (4 for double, 8 for float).

Putting it together:

3.9e9 * 16 * 2 * 2 * 4 = 998.4 GFlops (double)

3.9e9 * 16 * 2 * 2 * 8 = 1996.8 GFlops (single)

The measured values on my machine are a bit different, but close (1070 and 2151 respectively).

References:

https://www.agner.org/optimize/instruction_tables.pdf

https://www.agner.org/forum/viewtopic.php?t=56

https://gadgetversus.com/processor/amd-ryzen-9-5950x-gflops-...

Eh?

My 5950x (measured) flops are ~2 TFLOPS in single-precision, ~1TFLOPS in double precision (obviously, due to half the SIMD vector size). This is a desktop-class 16-core machine.

Does anyone honestly think politicians in a specific part of the world are not corrupt?

Just because American democracy is failing, it does not mean democracy is failing everywhere.

Another new lambda feature in C++20 is default constructability. I am surprised this is not mentioned in the article.

If that's your main example, you are in for a ride. Since asutton branch is over 15 years old almost at this point, and it was by design that no work should happen in LLVM until concepts make it into the standard.

Nice strawman, what does this have to do with anything that I wrote?

You went on and on about how there's heaps of "LLVM PhDs" (whatever that might mean) coming out of academia, so I gave you an example of someone working in academia who developed and contributed a key C++ feature to GCC.

I can give you a dozen examples, from constexpr, metaclasses, coroutines, modules, etc. where things made it much earlier into LLVM than GCC.

That's not my experience, and I have been using GCC and Clang daily on modern C++ codebases targeting the latest standard for the last 10 years.

From 2005 to 2014 GCC development severely stagnated, being much slower than clang, having horrible error messages when compared to clang, etc.

Yes, GCC's diagnostics have been trailing Clang's, though they have mostly caught up in the last few versions. But "much slower than clang" is flat out wrong, unless you mean compile-time performance. GCC has for years consistently produced more optimised code than Clang's, and it only in the last couple of years that the two compilers are essentially on performance parity.

AMD, Intel, ARM, ... they all have proprietary toolchains built on LLVM, and send and merge multiple diffs to LLVM upstream, every day.

I seriously doubt that AMD/Intel/ARM engineers are doing substantial work on C++20 features, but I'd be happy to be proven wrong :)

On top of that, many technology companies have built their whole platforms on top of LLVM.

That is irrelevant, as most of those companies are keeping their modifications to LLVM closed-source. They are not at all interested in fostering a healthy open-source ecosystem around LLVM.

GCC doesn't really have that.

This is just wrong. Just as a single example, the first ever C++ concepts implementation was written for GCC by Andrew Sutton, a University professor and co-author with Bjarne of the concepts proposal. LLVM's implementation came years later, and it's not as stable or complete to this day.

If Red-Hat and other private companies withdraw support, there are really few people familiar enough with GCC to keep it afloat, few people interested in learning and contributing because that won't land them industry jobs, etc.

Again, no. There is nothing in the 30+-years long history of GCC that suggests that this would happen.

No.

GCC existed and thrived long before companies started putting money into it. It would clearly suffer if, e.g., Red-Hat withdrew its support, but not nearly as LLVM would in the same situation.

The culture, history and governance of the two projects are very different and they do matter.

The fact that you think that climate change is a "political" topic speaks volume about the success of the right wing propaganda machine.

Korolev and his team made rapid advances. But even with the full weight of the Soviet economy behind them, they struggled to catch up. The main reason for this was organisational. Whereas the American programme was centrally planned and hierarchically managed, their Soviet counterparts seemed to be almost wilfully chaotic.

Oh my the irony.

As a scientist myself, I strongly disagree. If you spend a non-negligible amount of your time telling a computer what to do, you are, indeed, a programmer. And as such you should be expected to become a decently proficient programmer.

Physicists are not mathematicians, and yet they are required to acquire a relatively high degree of proficiency in maths because maths is a fundamental tool in their job, and nobody would argue otherwise.

The attitude of considering programming a mundane craft to be picked up as-you-go is the main reason why the scientific software landscape is such a shitshow.

/rant

Hello,

I have recently released version 0.3.0 of heyoka, a C++17 library for the numerical integration of ordinary differential equations (ODEs) using Taylor's method. The library uses automatic differentiation techniques and just-in-time compilation via LLVM to synthesize at runtime highly efficient and accurate numerical integrators.

Additional features include batch mode support to take full advantage of SIMD instructions in modern processors, and support for extended-precision computations using 80-bit and 128-bit floating-point types (if supported by the hardware/software platform).

The github page is here:

https://github.com/bluescarni/heyoka

The (WIP) documentation is available here:

https://bluescarni.github.io/heyoka/

Python bindings (via pybind11) are also available:

https://github.com/bluescarni/heyoka.py

WW1 was a total war. Fascism was a response to total war which conscripted every civilian into the military.

WWI was a contributing factor to the rise of fascism, which is a complex phenomenon whose roots date back at least to the late 1800s with the rise of nationalism throughout Europe, the unification of Germany, the growing distrust of liberal democracies at the turn of the century, etc. It was not a "direct result" of WWI.

Italy did not have an army of 500,000 soliders before WW1, no country did. The british empire's armed force was 80,000 -- and was one of the largest in the world. Where do you think 500,000 "soliders" came from? They were drafted from the population.

WWI was unparalleled in magnitude with respect to previous wars, but, as far as Italy is concerned, it did not involve directly the vast majority of the civilian population (around 34M at the time), which was never in a war zone or at risk of atrocities from the opposing force. The fighting was confined to the northeastern Alpine regions of Trentino, Veneto and Friuli. The Austrians made a small advance into the Italian territory before being decisively defeated on the Piave river. The industrial and agricultural heartlands of the country were largely intact at the end of the war, no major urban centres were captured or destroyed, and important land gains were made in the form of new territories formerly under Austrian control.

WWI was hell on Earth in the trenches, but no, Italy was not in disarray and did not experience mass death or poverty as a result of WWI.

(There were of course serious economic issues in the interwar period, but their genesis is in the great depression, not WWI)

I'm British and I know my own history very well. Read any book of the time, "Road to Wigan Peer" will give you the quality of poverty.

Life has been shit for most people for millenia, in Europe and elsewhere. But just take a look at any graph of the life expectancy over time in Europe and you will see that is has been steadily improving throughout the 20th century (with a couple of big temporary down spikes for the flu and WW2 - not WW1).

The Italian deaths in WW1 were overwhelmingly soldier deaths, as the fighting on Italian soil was limited to north-east border of the country (where incidentally I am from). The civilian population was largely unaffected by the war.

And as many again from the spanish flu.

Who talked about flu? You were talking about WW1, now you are pivoting to the flu?

And all of Europe was in a permanent condition of poverty until way into the 20th C. 80% of the population was poor working class even in 1970.

This is also grossly wrong. I suggest you better inform yourself about the 20-th century history of European societies before spouting more nonsense.

Fascism was a direct result of, and contingent upon, the mass death and poverty caused by WWI.

That is grossly wrong. There was no "mass death and poverty" in Italy during or after WWI.

So you're saying if the code was higher quality it would have fewer bugs? I mean, well, yeah.

That's not what I am saying, at all. You cannot do RAII in C.

My point was that I believe that most of the bugs under discussion here would not have happened if a language that provides RAII capabilities had been used.

The problem with solutions like RAII is that it doubles down on programmer infallibility, from "good programmers don't write bugs" to "good programmers correctly use RAII." You haven't really solved the actual problem unless you have tooling available that won't let non-RAII be checked in at all. Does that exist?

I don't understand what you are trying to say honestly.

If you think that RAII requires the same level of attention and care as manual malloc()/free()/new/delete, then this makes me wonder if you even know what the point of RAII is. Given the same "programmer quality" (for the lack of a better term), the use of RAII will certainly reduce the occurrence of memory mismanagement bugs.

For the tooling, you can use clang-tidy in C++ to enforce the use of smart pointers, make_unique, etc. E.g., see:

https://www.bfilipek.com/2017/12/why-uniqueptr.html

(I am sure there are other static checkers around that can spot the use of manual memory management functions, it's an easy thing to check for).

So, please don't put words in my mouth. The claim was never that RAII gives you the mathematical certainty of the absence of certain classes of bugs. Rather the claim is that in practice the use of RAII would have prevented most of the bugs presented here.

It's worth noting that many of these issues likely wouldn't have been possible with the use of RAII semantics.

That's really interesting!

How does it behave with almost-sorted data?

The laptop was seized due to his sexcapades, then discovered to have much more interesting data. Anthony Weiner's wife is Huma Abedin. She was deputy chief of staff to Clinton. Somehow, his laptop had come to contain lots of classified emails to/from Clinton.

I am aware of the facts (and Abedin "was" his wife). The FBI eventually established that the "new" emails were either personal or duplicate of already known emails.

You seem to be implying (correct me if I am wrong) that:

- Abedin was using Weiner's laptop to write the most "damaging" and "interesting" emails to Clinton,

- somehow, the emails sent to/from Weiner's laptop escaped months of extensive investigations by the FBI,

- somehow, the emails got erased from everywhere else apart from from Weiner's laptop and could be found only there (that's not how email works),

- somehow, in their criminal conspiracy, Clinton/Abedin forgot that Abedin had 650'000 (according to official reports) emails from the Clinton campaign on her husband's laptop - they erased all the damaging information from everywhere else but somehow forgot Wiener's computer (which she must have used extensively to accumulate that number of messages),

- 10 days of "around the clock" work by FBI agents couldn't have possibly established that most of 650k message where either "personal or duplicative" in nature[0].

Sorry, but that's just way too much mental gymnastic for my taste.

Again, the idea that Comey's public re-opening of the official investigation was somehow less damaging, from the point of view of public perception, than unsupported and unsubstantiated leaks from NYPD just does not hold water.

[0] https://www.washingtonpost.com/politics/fbi-director-comey-s...

What?

The problem was not the re-opening of the investigation (which the FBI could've done without informing or asking anyone), it was the fact that Comey decided on his own to inform the public (via congress, and against established department policy) that the investigation was being re-opened.

Weiner laptop was seized because of the underage sexting, what makes you think that this information would have been immediately devastating for Clinton? Weiner's sexcapades were well known before that, it was just another chapter in that saga.

Sorry but what you are implying just does not make any logical sense.

This is the same FBI that dealt a devastating blow to Clinton's campaign with the re-opening (and later re-closing, again with no charges) of the emails investigation shortly before the election.

Are you really suggesting that right after the election they "turned around" and started undermining the Trump presidency? What kind of sense does it make?

The FBI has been filing inaccurate FISA warrants for nearly two decades (the article on the Hill refers to incidents dating back to 2002/2003). Not really surprising in the post-9/11 era, where procedural abuses and law-enforcement power creep are tolerated if the justification is to "catch terrorists".

I didn't read anything suggesting that the FBI abused FISA warrants specifically against Trump people.