kllrnohj

33 ms·

691.
by kllrnohj 3y ago
https://en.cppreference.com/w/cpp/preprocessor/include __has_include and other compile-time checking would work here (eg type_traits and enable_if)
692.
by kllrnohj 3y ago
Hey, leave C++ out of this. This is a C problem. https://en.cppreference.com/w/cpp/feature_test
693.
by kllrnohj 3y ago
Yes, that's "Intel Turbo Boost Max Technology 3.0" https://www.tomshardware.com/reference/intel-favored-cpu-cor... The CPU has 2 golden cores that can hit max boost, and the others can't (at least n
694.
by kllrnohj 3y ago
The 14900K(S) has an unlimited boost duration. It'll run those clocks until your cooler can't handle it anymore, they never give up on their own. Intel added this not that long ago to differentiate the xx900k from the xx700k.
695.
by kllrnohj 3y ago
Factorio didn't get detected as a game properly so it was half on the vcache cores and half not on it. It's kinda heterogenous compute, and schedulers aren't that smart about it (at least Windows' isn't). If you set
696.
by kllrnohj 3y ago
Except as AMD is showing you can have both and not be at the mercy of hoping your OS's scheduler is able to consistently figure out what to do.
697.
by kllrnohj 3y ago
The 7800X3D is in a completely different universe for Factorio from the 14900KS, it's like 60% faster which is just absurd. Factorio absolutely loves that extra L3 cache. https://www.tomshardware.com/news/ryzen-7
698.
by kllrnohj 3y ago
> One way to look at VR headsets is that it's a better computer display -- as large and immersive as you want, without physical limitation. People prefer retina displays and will pay for multi-monitor setups, so we know people value
699.
by kllrnohj 3y ago
Only if everyone agrees on a central rendering model & feature set, which simply isn't the case. 2D rendering is not a solved problem, there are many different takes on it. Insisting all GUIs on a given device use a single system i
700.
by kllrnohj 3y ago
That seems like mostly bad advice. What you should do is open the door as fast as possible, before the car has begun to sink. There's not enough water pressure at that point to prevent it. If you freeze and hesitate then you're pa
701.
by kllrnohj 3y ago
Everything you just talked about is unrelated to the issue being discussed. This bug isn't a mismanagement of FD lifecycles, which yes Rust will do more safely out of the box than C++. This bug is a TOCTOU issue ( https://en
702.
by kllrnohj 3y ago
> Except, you know, Herb Sutter in the article we're supposedly discussing "Saying the quiet part out loud: CVEs are known to be an imprecise metric. We use it because it’s the metric we have, at least for security vulnerabilit
703.
by kllrnohj 3y ago
You're moving the goalposts so fast you could be competing with C++ for prioritizing performance over soundness. Reminder that your original claim was: > The problem definitely exists in C++, but it's not acknowledged as a prob
704.
by kllrnohj 3y ago
> because they don't take the issue as seriously because their spec says they don't have to. And yet they all quickly fixed the issue and nobody tried to hide behind "the spec" Should there have been a CVE? Probably.
705.
by kllrnohj 3y ago
That's also UB in Rust, Java, C#, etc... There's no language anywhere where a different process interacting with the file system at the same time isn't UB
706.
by kllrnohj 3y ago
FS races in Rust are UB as well, they're just scared to say that very explicitly. They hide behind this phrasing: "Many I/O functions throughout the standard library are documented to indicate what various library or syscalls
707.
by kllrnohj 3y ago
Or put another way, find a language, any language, that defines all possible scenarios of a file system race condition in a multi threading & multi process system. It's not possible to do such a thing, and of course nobody does. Th
708.
by kllrnohj 3y ago
Right, but security bugs don't all come from the language. They also come from logic errors. That's the "window" analogy here. If the language (door) is no longer the way people are getting into your house, then that&#x2
709.
by kllrnohj 3y ago
The libcxx & libc++ bugs both just pointed at the Rust CVE as a "this impacts us" - it doesn't seem like anyone bothered to file a CVE because they were too busy just fixing the issue. I don't see any evidence of thi
710.
by kllrnohj 3y ago
That statement really doesn't support your claim and unsurprisingly Rust has the same basic caveat because of course it does, it's not possible for a language to guarantee exclusive IO access to the filesystem. https://
711.
by kllrnohj 3y ago
> Saying it was fixed in two of the three C++ standard libraries is irrelevant, the language standard itself specifies that the behavior is undefined. Where does it say that? Please point to the spec that says remove_dir is allowed to ha
712.
by kllrnohj 3y ago
Where is the bug in the C++ standard? std::remove_all states: > 1,2) The file or empty directory identified by the path p is deleted as if by the POSIX remove. Symlinks are not followed (symlink is removed, not its target). > 3,4) Del
713.
by kllrnohj 3y ago
Links to where C++ marked it "won't fix" please (hint: you won't find them, both libc++ and libcxx treated them with severity & promptness and resolved the issue quickly)
714.
by kllrnohj 3y ago
The point is that trying to hit 0 would be a huge breakage that would fragment the language, and there's no actual evidence to suggest such a thing is actually necessary. It's like your front door's lock. It doesn't have
715.
by kllrnohj 3y ago
No it isn't, it's just a bug and it was fixed, just like it was for Rust. Nobody hid behind UB for this and the time from reporting the issue to fixing it was about 2 weeks for both libcxx and libc++ https://bugs.chromi
716.
by kllrnohj 3y ago
> It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed. Ca
717.
by kllrnohj 3y ago
The output resolution doesn't matter. The reason you tile is to improve locality and thus have more cache hits. For mobile GPUs, the cache is literally a specific tile buffer, but for nvidia (who also do this) the cache is just L2. But
718.
by kllrnohj 3y ago
For the 'CPU to GPU Copy Bandwidth' section the more likely reason GPU -> CPU copy is slow is there's no reason to do it. Adreno is unified memory, you can just mmap that GPU buffer on the CPU. This is done on Android via
719.
by kllrnohj 3y ago
It's significantly more bandwidth efficient to do tile based rendering however it has more performance cliffs and requires more game developer care to avoid hitting issues. For mobile SoCs (powervr, adreno, mali, and whatever apple cal
720.
by kllrnohj 3y ago
Not quite, not in the same way mobile GPUs do. Also I don't think AMD ever did the transition. They announced it (draw stream binning), but don't seem to have ever shipped it?

More ›