I am old enough to have witnessed how the climate has completely changed in Europe, where I live.
In the same place where I live now, when I was young there was permanent snow cover for 3 to 4 months.
During the last 10 years, there have been years with no snow and in the others a little snow has been present for 3 or 4 days of a year, when it melted the second day after falling.
I have not used again my winter boots and my winter jackets for the last 15 years or more.
This is really a huge change during less than a human lifetime.
What you've said is emotionally compelling, but scientifically very weak. Personal recollection is selective and location-specific. You’ve described a memory, not established a mechanism.
What you perceive as change isn't macro, it's micro.
It doesn't mean macro change isn't happening, but it's not happening on our timescale.
Just look at any glaciar in the Alps (or almost anywhere in the world really). Over the last 50 years, your liftime, there have been enourmous changes.
You can paste this exact response under your other post, as well. Emotionally compelling, scientifically weak. Worth nothing.
But also, what you wrote is just wrong. There are plenty of measurable, significant, ood effects in the last few decades on the climate and its impact.
Here’s one study onglacier retreat over the last 20 years.
The bug appears to have been introduced in some FreeBSD 13 version.
I run FreeBSD servers that do not have this bug. In my "kern_exec.c" there is no "consume" anywhere. There is also no "memmove" at all.
That file was last patched in 2024, but whatever changes had introduced that bug, they were not back-ported to older FreeBSD versions, so those are not affected.
A much older language that does not have operator precedence is APL.
This is the right choice for a language with a great number of operators.
In C they have tried to minimize the number of parentheses in expressions, but for this they have created far too many levels of precedence between operators, which had the opposite effect to that intended, since people now prefer to insert superfluous parentheses, to avoid having to remember all those levels of precedence.
Actually the column-major order of Fortran is more efficient for some linear algebra operations than the order of C, which has been inherited by many modern languages that do not care about high performance in scientific computations.
So I would say that the culprit for interoperability is C and its descendants, not Fortran or Julia. The designers of C and of the languages that have imitated C have not given any thought about which order for multi-dimensional arrays is better, so the users of such languages do not have any right to blame for interoperability other languages that have done the right thing. Even if the Fortran order had not been better, it had already been used for 20 years before C, so there was no reason to choose a different order.
C has chosen to store arrays in the order in which they are typically read by humans when written on paper, but this is a choice like the choice between big-endian and little-endian, where big-endian was how Europeans wrote numbers, but little-endian is more efficient on computers.
An example of why column-major order is preferable, is the matrix-vector product, i.e. the evaluation of a function that maps linear spaces.
The matrix-vector product should not be done as it is typically taught in schools, by scalar products of rows of the matrix with the vector, because this is less efficient, by making more memory accesses. The right way to compute a matrix-vector product is by doing AXPY operations between columns of the matrix and the vector operand (segments of the output of the AXPY operations are held in registers until all partial AXPY operations are accumulated, avoiding memory accesses). In this case, you need to read columns of the input matrix for each AXPY operation, which is much more efficient when the elements of a column are stored compactly in memory, avoiding the need of strided accesses.
The same thing happens for matrix-matrix products, which must not be done in the naive way taught in schools, by scalar products of rows of the first matrix with columns of the second matrix, but it must be done by tensor products of columns of the first matrix with rows of the second matrix.
> Actually the column-major order of Fortran is more efficient for some linear algebra operations than the order of C, which has been inherited by many modern languages that do not care about high performance in scientific computations.
This is a plausible assumption to make but unfortunately it is not true at large. Especially when the traditional sizes are exceeded say n >= 2000 certain operations such as LU can be improved in terms of performance with C-major arrays. However the correct statement is you lose at some place you win at other. There are certainly linalg operations that F-major can give you more performance. However it is also true for C-major layout.
In your example matrix vector product or any BLAS2 or BLAS3 level operations you can also swap out the for loop order to convert things around (row*col buffer multiplication vs sum of weighted column sum interpretation). In particular matrix norm operations are the only exceptions (abs column sum, row abs sum etc.) that certain norms prefer certain orders. In fact if you go into the Goto method deep enough you'll see that internal order is a bit like Morton ordering to fit things into L1 Cache.
The reason why column-major is preferred is historical and requires more surgery to get it running with C-major ordering. Trust me I tried but it's too much work to gain not so much. Maybe someday when I retire I can attempt it. Hence I kept it column major in my retranslation of LAPACK https://github.com/ilayn/semicolon-lapack
Instead I implemented a "high"-performance AVX2 matrix transpose operation so that swapping the memory layout is trivial compared to the linalg cost.
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.
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.
I do not know on what data you base your sentence "Intel's own Panther Lake CPU tile is on 18A and it's extremely disappointing in terms of perf/watt and raw perf."
Panther Lake does not have great raw performance, because for now Intel has not succeeded to obtain in their new 18A CMOS process clock frequencies as high as they get in the older TSMC 3-nm process used for their previous Arrow Lake H CPU generation and the CPU cores of Panther Lake have only minor changes that can affect performance in comparison with Arrow Lake/Lunar Lake.
On the other hand, from the published reviews that I have seen, Panther Lake has significantly better performance per watt than Arrow Lake H, which can be attributed only to the Intel 18A process when compared with the TSMC 3 nm process.
The energy efficiency i.e. performance per watt ratio of CPUs is mainly determined by the fabrication process and not by the CPU design, as long as the CPU designers are competent enough (unlike the single-thread performance, which is determined mainly by the CPU design).
So there is no doubt that Apple CPUs made with the Intel 18A process will have better performance per watt than those made with a TSMC 3-nm process. Moreover, because Apple CPUs can reach a given level of performance at lower clock frequencies, they should be much less affected by the lower clock frequencies attainable with Intel 18A than the Intel CPUs.
We also do not know whether Apple intends to use the Intel 18A process (currently used for Panther Lake laptop CPUs and Clearwater Forest server CPUs), or only its successor, Intel 14A.
The most important one for efficiency is ST perf/watt. MT perf/watt is largely based on how many cores there are. You can achieve better MT perf/watt simply by having more cores (more transistors) and run them at lower clocks. Panther Lake also has an entirely new MT config with 3 tiers of cores vs 2 for Arrow Lake.
For ST perf/watt, it loses to LNL.
Keep in mind that LNL and Arrow Lake used N3B, and future N3 nodes have been much more efficient. Panther Lake CPU is also a new design which should have improved perf/watt automatically regardless of node.
Based on this, one can deduce that Intel 18A is likely a bit worse than N3B and perhaps equivalent to N4P. Keep in mind that N3B went into production in late 2022 and N4P was a 2021 node.
ARL is the relevant comparison point. LNL was specifically designed and targeted for low power. It's not just the node but the design that is relevant. Even for single core perf, the design dictates which other parts of the chip can be turned off. LNL was optimized there at the expense of total performance. PTL has 1.7x-2x multi core performance vs LNL. These are apples and oranges.
When a new node is introduced, it will usually say something like "+15% at ISO power" or "-30% at ISO performance".
The fact that Panther Lake could not beat LNL on ST perf/watt is telling of the node.
PTL most likely derived its design on LNL. Overall, Arrow Lake was a complete disaster of a design. PTL was a better high performance design for sure and uses different core config for MT.
There is a reason why such a pattern is frequent in LLM-generated text.
Any good human-written text that provides useful information is likely to highlight in this way or in equivalent ways the contrast between what the reader is expected to incorrectly believe and the reality.
When the reader already knows what the text has to say, that text is superfluous.
Therefore a text that provides new and unexpected information, so it is a useful text, must use some means to explain to the readers the errors of their ways.
It may use simple superposition like "it is not ... it is ..." or it may be more verbose and add "but", "however", "nonetheless" etc.
I believe that it is counterproductive to use this kind of pattern as a method for detection for AI-written texts, because it is normal for it to exists in useful human-written texts.
What should be commented is whether that claim is true, i.e. whether indeed the second part with "it is ..." is true, or whether all of the pattern is superfluous, because none of the expected readers is not already aware that the first part with "it is not ..." is true.
No citation is needed when you see the changes with your own eyes, which happened at least in Europe, where I live.
reply