I still have one of those lying around in the draw. It's the backup phone and every time I or my partner needs to use it I am surprised at how well it still works.

I found it completely unreadable, similar to reading code without syntax highlighting.

Maybe he should have had AI fix up the grammar/spelling for him...

Which is weird because it's pretty straightforward to work out if you need sunscreen or not:

  * Is it any month other than May-August?  
  
  * Is it after 10am or before 4pm?  
  

Probably need some sun screen.

If you have very light skin you might want to increase the timeframe by an hour.

And if you really want to optimise your sunscreen usage and not use it if you don't have to, the real-time UV index from ARPANSA is the way to go (https://www.arpansa.gov.au/our-services/monitoring/ultraviol...).

All other apps simply display the expected UV index given the time of the day and the day of the year.

Sunscreen for the face should just be daily. My dermatologist recommends it even in Berlin in the Winter.

And then, this is most critical, use mineral or at least creamy sunscreen (sprays barely do anything) and put it on a few minutes before sun exposure - not when you start feeling it.

Agree that the UV index is not particularly useful - it's kind of obvious. Still good to know though.

I have the same specs in my work machine.

Task manager takes 10 seconds to load the list of processes. Right-click on the desktop takes about 1.5-2 seconds to show the 'new' context menu. Start menu is actually fast to start drawing but has a stupid animation that takes about half a second to fully load.

I sort of understand how the anti-consumer 'features' (ads) get added to a piece of software. But I have no idea how they manage to continuously degrade the experience of existing parts of the system for seemingly no one's benefit.

Are there any details around how the round-trip and exchange of data (CPU<->GPU) is implemented in order to not be a big (partially-hidden) performance hit?

e.g. this code seems like it would entirely run on the CPU?

    print!("Enter your name: ");
    let _ = std::io::stdout().flush();
    let mut name = String::new();
    std::io::stdin().read_line(&mut name).unwrap();

But what if we concatenated a number to the string that was calculated on the GPU or if we take a number:

    print!("Enter a number: ");
    [...] // string number has to be converted to a float and sent to the GPU
    // Some calculations with that number performed on the GPU
    print!("The result is: " + &the_result.to_string()); // Number needs to be sent back to the CPU

Or maybe I am misunderstanding how this is supposed to work?

"We leverage APIs like CUDA streams to avoid blocking the GPU while the host processes requests.", so I'm guessing it would let the other GPU threads go about their lives while that one waits for the ACK from the CPU.

I once wrote a prototype async IO runtime for GLSL (https://github.com/kig/glslscript), it used a shared memory buffer and spinlocks. The GPU would write "hey do this" into the IO buffer, then go about doing other stuff until it needed the results, and spinlock to wait for the results to arrive from the CPU. I remember this being a total pain, as you need to be aware of how PCIe DMA works on some level: having your spinlock int written to doesn't mean that the rest of the memory write has finished.

We use the cuda device allocator for allocations on the GPU via Rust's default allocator.

Have you considered “allocating” out of shared memory instead?

Why are you assuming that this is intended to be performant, compared to code that properly segregates the CPU- and GPU-side? It seems clear to me that the latter will be a win.

I am not assuming it to be performant, but if you use this in earnest and the implementation is naive, you'll quickly have a bad time from all the data being copied back and forth.

In the end, people program for GPUs not because it's more fun (it's not!), but because they can get more performance out of it for their specific task.

I had the T431s for over a decade as well.

Replaced the keyboard (orange juice spillage), screen (upgraded to a higher resolution panel), hdd (to an SSD of course), RAM, Wifi adapter (Wifi 6) as well as the battery.

I now use an X1 Nano and while it's nice (and very light!) I am sad that the upgradability is nowhere near as good.

I ran into a similarish issue in C++ (MSVC++) where a small change that improved an error message led to a 10% slowdown.

The function was something like:

  int ReturnAnswerIfCharIsValid(char* c)
  {
    if(c == nullptr)
      throw std::exception("ERROR!");

    return 42;
  }

The exception line was changed to something like:

  throw std::exception("Char is not valid, please fix it!"); // String is now longer

The performance of this hot-path function went down the drain.

I fixed it by replacing the exception call with yet another function call:

  if(c == nullptr)
     ThrowException();

Other fixes might have included something like __forceinline in the function signature.

It’s weird that something that should be in a constants pool would hit the inlining threshold.

I have done this specifically with the second item in the list in the OP.

Not only did I do it to get free shipping, I got it to get free international shipping.

For extra bonus CO2 points, the other item was coming from a different country. So I basically paid $0.42 to have a single packet of kool-aid shipped across the pacific ocean.

(I'd never had kool-aid before and I must say I was disappointed.)

> The only part that irritates me is having to interact with the GTK file chooser (file open dialog). Someday I might be annoyed enough to replace it.

That's probably my only annoyance as well. Is there an easy way to replace it? Not being able to see the path as a string is very "un-linux".

I've been using XFCE for several years on 4k screens and I agree that it's not great out of the box.

Once you've set it up it works pretty well though.

Now if only I could remember what I did to get it working nicely...(luckily I've had the same installation of XFCE on my machine for the past 5 years so haven't had to fiddle with that in a while)

I just set dpi to 128 or 192. The out-the-box 96 could do with changing.