> the proportion of all 2n-bit values that can be generated by the product of two n-bit values goes to zero as n becomes large. This means that if you have, say, 10000000-bit integers multiplying 10000000-bit integers, you’d expect relatively few 100000000000000-bit integers to be produced.
That should be "relatively few 20000000-bit integers", right?
At least in the UK, the main high-street retailers will only stock goods from reputable brands with a (relatively) decent track record and safety standards. I don't believe there is any intersection between products sold on Temu and e.g. Argos, John Lewis.
Not in The Netherlands. Plenty of stores that stock chargers identical to the ones on AliExpress and Temu. Action, Big Bazar, SoLow.
Edit: Reply to lozenge as I am still rate-limited by HN. Some of them get recalled, the vast majority of them are still being sold and could burn your house down.
This talking point is everywhere in this thread. But bear in mind that you have no clue whether two chargers (for example) are the same without disassembling them and checking. Noname Chinese manufacturers are very good at producing things that are superficially similar to other things. It does not mean that two widgets that look similar actually are.
The main difference with most physical stores is that those will accept responsibility for the stuff they sell, because otherwise regulations would put them out of business.
Besides the fact that Lunar Lake has a lower consumption in the memory interface, which has nothing to do with the fabrication process, single-thread benchmarks cannot be used to compare CPU fabrication processes.
Both the absolute performance and the performance per watt in single-thread benchmarks are determined mainly by the CPU design and they are only slightly constrained by the CPU fabrication process.
Only the multithreaded benchmarks are useful for comparing CMOS fabrication processes, because the performance in multithreaded benchmarks (with a given cooling system) is limited mainly by the energy required to switch a logic gate, which is a characteristic of the fabrication process, and they are only weakly dependent on the CPU design, as long as the CPU design does not have obvious mistakes.
In multithreaded benchmarks, CPUs work at a fixed power consumption, determined by the maximum allowable temperature and the cooling system. A fixed power means a fixed number of gates that switch per second. The completion of a given benchmark requires a similar number of gate switchings in well designed CPUs, in which case the performance in such a benchmark is fully determined by the fabrication process. Deviations from proportionality appear when some CPUs need much less gate switchings than others to complete some work, which happens for example when a CPU has wider vector or matrix execution units, e.g. by supporting AVX-512 or SME or AMX.
On package memory disproportionally affects idle power consumption more than load. In Cinebench 2024, which is a heavy load test, on package memory likely makes little difference.
ST is far better than MT for this node comparison. MT is heavily influenced by core count, clock speed, core configuration. Panther Lake also has 3 tiers of cores compared to Arrow Lake's 2. The architecture for MT is entirely different.
Meanwhile, for ST, a core is a core. It's less or not affected by architectural changes to core configurations.
> With the new Panther Lake mobile processors, Intel has managed to successfully combine the two previous generations, Arrow Lake and Lunar Lake, as the performance is even better than with Arrow Lake, while efficiency has been improved at the same time. Even with low power limits, the performance is very competitive, and Intel (in conjunction with the new GPUs) is therefore the better choice for slim laptops.
The performance with LNL is not apples-to-apples, like the comparison with Arrow Lake H.
LNL has a much lower power consumption in the memory interface, like the Apple CPUs, which has nothing to do with the fabrication process. Also LNL is a lower performance CPU, for which it is normal to have better energy efficiency.
Only the comparison between Panther Lake and Arrow Lake H, which have equivalent structures, can be used to compare the Intel 18A and the TSMC 3-nm fabrication processes.
This comparison shows that Intel 18A ensures a better performance per watt, i.e. energy efficiency, which leads to a better multithreaded performance, but the TSMC 3-nm process, at least for now, allows higher maximum clock frequencies, which make possible a higher single-thread performance.
On-package memory disproportionately affect idle power more than load power. The benchmark was done with Cinebench 2024 which is a heavy load test. Therefore, LNL's on package memory would have made little to no difference overall to perf/watt in Cinebench 2024 ST.
Only the comparison between Panther Lake and Arrow Lake H, which have equivalent structures, can be used to compare the Intel 18A and the TSMC 3-nm fabrication processes.
Panther Lake uses a new core design which likely contributed to better perf/watt regardless of which node was used. For example, Zen3 had a 19% increase in IPC despite being on the same N7 family node as Zen2. Panther Lake has 3 tiers of cores instead of 2 in Arrow Lake. The MT design is very different. New core and layout designs can make a huge difference in efficiency on the same node.
This comparison shows that Intel 18A ensures a better performance per watt, i.e. energy efficiency, which leads to a better multithreaded performance, but the TSMC 3-nm process, at least for now, allows higher maximum clock frequencies, which make possible a higher single-thread performance.
We should compare ST perf/watt instead of MT. MT has too many factors including core count, die size, transistor count, clock speed.
Based on ST perf/watt, Intel 18A is likely a bit worse than N3B (2022 node) and a bit better than N4P (2021 node).
The Panther Lake cores, i.e. Darkmont and Cougar Cove are the Arrow Lake/Lunar Lake cores, i.e. Skymont and Lion Cove, ported from the TSMC 3 nm to the Intel 18A fabrication process.
The Panther Lake cores have only minor changes, i.e. bug fixes and the addition of a new mechanism for interrupts and exceptions, FRED. A preliminary version of FRED is likely to have already been implemented on Arrow Lake/Lunar Lake, but if so it was disabled there after production.
In any case FRED will not cause improvements in the present benchmarks, as it is used only inside the operating system and the current operating systems are unlikely to have been updated to use it anyway.
In contradiction with what you say, ST performance or performance per watt cannot be used to compare fabrication processes but only the multithreaded performance can bu used for this purpose.
Single-thread performance is affected by a lot of factors that have nothing to do with the fabrication process, but all those have little or no influence on multithreaded performance.
The reason is that in any well optimized MT workload, the CPU runs at a constant power consumption. This eliminates the influence of all factors mentioned by you.
I have already explained in another comment that a constant power consumption means a constant number of gate switchings per second, which is determined by the energy required to switch a logical gate, which is a characteristic of a fabrication process.
When a given amount of work is done by a benchmark using the same algorithm, well-designed CPUs will need approximately the same number of gate switchings to complete the work, regardless of the number of cores included in a CPU.
Significant variations of the numbers of gate switchings can be caused only by architectural differences like the width of vector and matrix execution units. Smaller variations are caused by various quality characteristics of a CPU core design, like the frequencies of branch mispredictions and of cache misses, which should be similar for CPU design teams that do not differ much in competence.
When we compare equivalent cores in different fabrication processes, like Arrow Lake H vs. Panther Lake, the multithreaded benchmarks are almost unaffected by anything else except the fabrication process, assuming that the cooling systems are also equivalent.
The reason is that in any well optimized MT workload, the CPU runs at a constant power consumption. This eliminates the influence of all factors mentioned by you.
This makes no sense because in ST perf/watt, we're normalizing watt already.
> there are testimonies of smart home devices like anti-theft alarms or automatic doors, that stop working whenever [...] because their backends rely on Cloudflare.
The fault here lies 100% with horribly designed IoT devices that turn into bricks when they lose internet connection.
Yeah the horribly designed alarm system that can't alert a central authority that something has gone wrong. Maybe we should just put huge air raid sirens on our homes instead?
Depends on the VPN, I remember Nord had a private p2p network that allowed users of their VPN service to communicate directly with each other without exposing their p2p services to the greater internet.
Granted, its been a lomg time since I used Nord, not sure if they still offer that service.
The comment probably refers to data races over memory access, which are prevented by usage of `Send` and `Sync` traits, rather than more general race conditions.
I see, but that's not the point of my comment. I don't know rustlang, perhaps I could address that if someone translated the rust-specific parlance to more generally accepted terms.
I'm not sure I understand the point of your comment at all.
Rust does, successfully, guarantee the lack of data races. It also guarantees the lack of memory-unsafety resulting from race conditions in general (which to be fair largely just means "it guarantees a lack of data races", though it does also include things like "race conditions won't result in a use after free or an out of bounds memory access").
If by address it you mean "show how C/C++ does this"... they don't and this is well known.
If by address it you mean "prove that rust doesn't do what it says it does"... as that point you're inviting someone to teach you the details of how rust works down to the nitty gritty in an HN comment. You'd be much better off finding and reading the relevant materials on the internet than someones off hand attempt at recreating them on HN.
The point of my comment is that in my experience, incompetently written, overly-cautious code tends to be more safe at the expense of maintainability and/or performance.
Sadly, I don't know rustlang, so I can't tell if the inability to describe its features in more commonly used terms is due to incompetence or the features being irrelevant to this discussion (see the title of the thread).
The thing is you aren't really asking about a "feature" of rust (as the word is used in the title of the thread), unless that feature is "the absence of data races" or "memory safety" which I think are both well defined terms† and which rust has. Rather you're asking how those features were implemented, and the answer is through a coherent design across all the different features of rust that maintains the properties.
As near as I can tell to give you the answer you're looking for I'd have to explain the majority of rust to you. How traits work, and auto traits, and unsafe trait impls, and ownership, and the borrow checker, and for it to make sense as a practical thing interior mutability, and then I could point you at the standard library concepts of Send and Sync which someone mentioned above and they would actually make sense, and then I could give some examples of how everything comes together to enable memory safe, efficient, and ergonomic, threading primitives.
But this would no longer be a discussion about a rust language feature, but a tutorial on rust in general. Because to properly understand how the primitives that allow rust to build safe abstractions work, you need to understand most of rust.
Send and Sync (mentioned up thread) while being useful search terms, are some of the last things in a reasonable rust curriculum, not the first. I could quickly explain them to someone who already knew rust, and hadn't used them (or threads) at all, because they're simple once you have the foundation of "how the rest of rust works". Skipping the foundation doesn't make sense.
† "Memory safety" was admittedly possibly popularized by rust, but is equivalent to "the absence of undefined behaviour" which should be understandable to any C programmer.
> The point of my comment is that in my experience, incompetently written, overly-cautious code tends to be more safe at the expense of maintainability and/or performance
Well, yes, but that's the whole value of Rust: you don't need to use these overly-cautious defensive constructs, (at least not to prevent data races), because the language prevents them for you automatically.
Safe Rust does. To the extend Rust interfaces that wrap kernel APIs will achieve safety for the drivers that make use of them remains to be seen. I think it will indeed do this to some degree, but I have some doubts whether the effort and overhead is worth it. IMHO all these resources would better be invested elsewhere.
Thats kinda the problem, there are concepts in rust that don't have equivalents in other common languages. In this case, rust's type system models data-race-safety: it prevents data races at compile time in a way unlike what you can do in c or c++. It will prevent getting mutable access (with a compile time error) to a value across threads unless that access is syncronized (atomics, locks, etc)
And from what I can see, rustlang mutability is also a type system construct? I.e. it assumes that all other code is Rust for the purpose of those checks?
> rustlang mutability is also a type system construct?
Yes
> I.e. it assumes that all other code is Rust for the purpose of those checks?
Not exactly, it merely assumes that you upheld the documented invariants when you wrote code to call/be-called-from other languages. For example that if I have a `extern "C" fn foo(x: &mut i32)` that
- x points to a properly aligned properly allocated i32 (not to null, not to the middle of un-unallocated page somewhere)
- The only way that memory will be accessed for the duration of the call to `foo` is via `x`. Which is to say that other parts of the system won't be writing to `x` or making assumptions about what value is stored in its memory until the function call returns (rust is, in principle, permitted to store some temporary value in `x`s memory even if the code never touches x beyond being passed it. So long as when `foo` returns the memory contains what it is supposed to). Note that this implies that a pointer to the same memory isn't also being passed to rust some other way (e.g. through a static which doesn't have a locked lock around it)
- foo will be called via the standard "C" calling convention (on x86_64 linux this for instance means that the stack pointer must be 2-byte aligned. Which is the type of constraint that is very easy to violate from assembly and next to impossible to violate from C code).
That it's up to the programmer to verify the invariants is why FFI code is considered "unsafe" in rust - programmer error can result in unsoundness. But if you, the programmer, are confident you have upheld the invariants you still get the guarantees about the broader system.
Rust is generally all about local reasoning. It doesn't actually care very much what the rest of the system is, so long as it called us following the agreed upon contract. It just has a much more explicit definition of what that contract is then C.
Also we can (in 2024 Edition) say we're vouching for an FFI function as safe to call, avoiding the need for a thin safe Rust wrapper which just passes through. We do still need the unsafe keyword to introduce the FFI function name, but by marking it safe all the actual callers don't care it wasn't written in Rust.
This is fairly narrow, often C functions for example aren't actually safe, for example they take a pointer and it must be valid, that's not inherently safe, or they have requirements about the relative values of parameters or the state of the wider system which can't be checked by the Rust, again unsafe. But there are cases where this affordance is a nice improvement.
Also "safe" and "unsafe" have very specific meanings, not the more widely used meanings. It's not inherently dangerous to call unsafe code that is well written, it's really more a statement about who is taking responsibility for the behavior, the writer or the compiler.
I like the term "checked" and "unchecked" better but not enough to actually lobby to change them, and as a term of art they're fine.
Yes. Just like C++ "const" is a type system construct that assumes all other code is C++ (or at least cooperates with the C++ code by not going around changing random bytes).
As far as I can tell, ANY guarantee provided by ANY language is "just a language construct" that fails if we assume there is other code executing which is ill-behaved.
a data race is specific kind of race condition; it's not rust parlance, but that specificity comes up a lot in rust discussions because that's part of the value
> since Rust is not the only language susceptible to data races.
The point is rather that it’s not. The “trait send sync things” specify whether a value of the type is allowed to be respectively move or borrowed across thread boundaries.
I mean, reliably tracking ownership and therefore knowing that e.g. an aliased write must complete before a read is surely helpful?
It won't prevent all races, but it might help avoid mistakes in a few of em. And concurrency is such a pain; any such machine-checked guarantees are probably nice to have to those dealing with em - caveat being that I'm not such a person.
When I'm familiar with the source, the headlines are enough for me to know if I want to read, navigating the folders is super quick, and the feed indicator makes adding new ones very easy too.
Or you can adblock and donate on Patreon etc. to your favourite channels. Not every channel you watch will benefit, but a much higher percentage of your money goes to creators, who generally get a less than fair deal from platform holders. Same goes for buying music on Bandcamp + pirating, versus a music streaming subscription.
That should be "relatively few 20000000-bit integers", right?