> It is disputed whether the name Wi-Fi is short-form for 'Wireless Fidelity',[34] although the Wi-Fi Alliance did use the advertising slogan "The Standard for Wireless Fidelity" for a short time after the brand name was created,[31][35] referenced "the Wi-Fi (Wireless Fidelity) logo" in a white paper[33] and the Wi-Fi Alliance was also called the "Wireless Fidelity Alliance Inc." in some publications.[36] IEEE, a separate but related organization, has stated "WiFi is a short name for Wireless Fidelity" on their website.[37][38] The name Wi-Fi was partly chosen because it sounds similar to Hi-Fi, which consumers take to mean high fidelity or high quality. Interbrand hoped consumers would find the name catchy, and that they would assume this wireless protocol has high fidelity because of its name.[39]
So it’s not really safe to say it’s not meant to mean wireless fidelity, in fact it sounds pretty likely.
You could say this about every QoL feature though. That’s not a reason to not do it though, it adds up and at some point other apps that do bother to make their apps as good as possible will become more popular than yours.
> The CPU doesn't really see functions, it just sees instructions. Functions are a convention on top of the machine code.
Not really true, most instructions set have instructions specifically to implement functions as found in normal programming languages. x86 has CALL and RET for example.
they have instructions for implementing them, but the important point here is that functions are still only defined by instructions that are executing between a call and ret instruction (or their equivalent more spelled-out equivalent operations), and not only can these not match up with what the compiler considers a function (for useful reasons like tail-calls as well as not-useful reasons like compiler bugs and UB), it might not be statically obvious exactly what instructions these are. So the CPU in practice has only a rough guess of where the function boundaries are (it might use these guesses for things like branch prediction, but they don't define the visible execution of the code beyond the nuts and bolts of what those instructions actually do).
Better CPU selection. Embedded almost always have power requirements and you need to put your CPU into a low power mode not a loop which is running fast. You can also design your hardware such that you can turn the power off completely in these cases (or perhaps reboot).
Now that I think of it, a different project (I worked just down the aisle, but I wasn't on it) solved a lot customer complaints by turning all the "while(1);" loops into blink an error code - which since it does IO is defined behavior. Which probably is the correct answer to your question - don't just spin doing nothing, spin in such a way that the user has a clue why nothing is working (and in turn you can find out and perhaps fix real world bugs)
This is myopic. In many cases it takes time, and sometimes considerable programming effort, to enter and exit low power modes. So you don't do it willy-nilly; you do it when you believe the system has quiesced. That means, on a purely interrupt driven system that is not yet ready to sleep, the code may very well be spinning in an empty infinite loop somewhere.
There's no need to inform the "user" because there's nothing wrong with the system. Its simply waiting until the benefit of sleeping outweighs the cost of getting there.
It may take 100s of instructions to enter a deep sleep state, and 100s to 1000s more to exit it. If you anticipate having to service an event sooner than that, you don't enter sleep at all (especially since there's likely a point at which you're committed to sleep, and have to go all the way down in order to come right back out again). Instead, you hang around twiddling your thumbs until the event comes along.
Now if your processor has a halt/wait-for-interrupt instruction (most do but some don't) you can escape into assembly and use that. But it probably makes little to no difference to energy utilization, and of course its not portable. A nice while (true); would seem obvious, except that the C++ committee insisted that it wasn't.
Just one example of where the committee lost sight of the fact that it was defining an imperative
programming language.
I'm also confused that an uncalled function is even compiled and linked, wouldn't it make sense to remove it entirely if the compiler can detect that it's never called?
If it's declared as static, maybe (well, usually, in my experience. You'll also usually get an unused warning). Otherwise the compiler can't assume some other compilation unit won't want it. Linkers can perform a garbage collection pass but they don't often do it by default and they often need finer grained information from the compiler (see the gcc arguments --ffunction-sections and -Wl,--gc-sections)
I can understand adding the 'unreachable' function to the object file, I can even understand plugging it into the final executable, what I (and most other people) object to is making it the de-facto entry point.
This is literally the opposite behaviour compared to what is written in the source code, even when you "assume the infinite loop terminates".
That's the problem with UB, once you hit it (or even have it in your code), you can't really trust anything about the execution anymore. That the function is called isn't something the compiler does on purpose, it's just that the main function is compiled empty due to the UB and the function directly behind it is executed because the CPU just keeps looking for the next instruction.
> What I found is that this is common in embedded and kernel code as a halt-on-error pattern. When a fatal error occurs and there’s no operating system to exit to, you simply stop:
If this is a genuine use case, I wonder why the language can't just introduce a built-in function for it. For example, std::get_stuck_here(). Then the compiler would know not to optimize this away. The implementation under the hood could still be an infinite loop, but the compiler would not have to guess why it's there.
one could already add loads off a volatile and portably prevent the loop from being optimized. But there was already a lot of existing embedded code that had this sort of loop, (and more will be written as it is an existing idiom) which the committee wanted to un-break.
Because a compiler being allowed to assume that a loop always terminates gives it more room to optimize the 99% of loops that aren't supposed to run until the heat death of the universe.
Or you could just detect while loops with constant condition (like the C standard) and not touch any programs that don't exhibit UB while allowing infinite loops for other use cases at zero runtime cost and negligible compile cost.
Do you not think that stealing requires the original owner to lose access?
If I sneak into your home, take apart the coffee machine, measure everything, put it back together and go home and build a copy to have my own, did I steal your coffee machine?
Can we not just stick to calling it copyright infringement?
> Do you not think that stealing requires the original owner to lose access?
No.
> If I sneak into your home, take apart the coffee machine, measure everything, put it back together and go home and build a copy to have my own, did I steal your coffee machine?
Not mine. But the company that made the coffee machine. It is stealing IP.
> Can we not just stick to calling it copyright infringement?
It is just a fancy way of saying you stole someone's IP. You can call it infringement if it makes you feel good. But the act is the same end of the day.
The multiplication comparison makes no sense because humans don’t learn by multiplying numbers to change weights. It’s like comparing the lubrication oil consumption of a car to the cooking oil consumption of a human to compare the carrying capacity. That’s an implementation detail inside the GPU and doesn’t let you compare how much they learn. Otherwise, a human would learn much less in their whole life than a GPU does in one second.
> That’s an implementation detail inside the GPU and doesn’t let you compare how much they learn.
The same applies to "horse-power". Yet we have no issue making the comparison anyways and HP has become an industry standard. I don't understand why we have to bend-over backwards when it comes to humans being exploited by AI companies.
> The same applies to "horse-power". Yet we have no issue making the comparison anyways and HP has become an industry standard.
Yeah, which is why it's only used to compare cars etc. among each other.
Nobody would calculate the equivalence of a car to a horse using their HP rating because a horse doesn't even have 1 HP. They have more or less depending on the task you're doing. It was a marketing thing at the time to make steam engines look good.
In france, cars are taxed by their engine power. Do you think pedestrians walking on the sidewalk should be taxed according to their power on an ergometer too?
Do you not see that different things need to be handled differently before the law and just taking an arbitrary measure that you can technically apply to both doesn't capture the situation?
> It was a marketing thing at the time to make steam engines look good.
Except it is actually taxed based on HP in various countries. Austria, Belgium, Spain, Italy use engine horsepower to levy annual car taxes.
> In france, cars are taxed by their engine power. Do you think pedestrians walking on the sidewalk should be taxed according to their power on an ergometer too?
Citizens are paying taxes for betterment of roads irrespective of whether they own vehicles or not. In India, betterment charges are collected for construction/maintenance of roads if you own land. Property tax collected every year has a certain allocation for maintenance/upkeep of roads. Apart from that, money from direct and indirect tax collections are allocated for roads upkeep as well. It just is done indirectly rather than a direct road tax if you have vehicles (road tax is actually an extra tax you pay APART from taxes you already pay for upkeep/maintenance of roads).
> Do you not see that different things need to be handled differently before the law and just taking an arbitrary measure that you can technically apply to both doesn't capture the situation?
Except in your own examples it can easily be shown that it is not handled differently. Some countries use HP while others use CC. But end of the day, they use some measurement to determine taxes to be paid. It is not free.
EDIT: Do you not see that different things need to be handled differently before the law and just taking an arbitrary measure that you can technically apply to both doesn't capture the situation?
To answer this in more detail: HP/CC and all other measurements were created to equalize with human specific metrics. Bridges, for example, have safety measured based on how much weight it can sustain at any given time (called load limit). Weight, in this specific case, is an equalizing measurement (it can be in tonnes, kN, PSF, Pa etc). A bridge can hold ten thousand humans or thousand trucks. You can argue that a "human" may not weigh 100 kgs or a truck may not weigh exactly 1 ton. That's fine. It is a rough approximate to equalize unequal entities.
> Except in your own examples it can easily be shown that it is not handled differently.
I was talking about humans vs. cars as an analogy to you comparing GPUs and cars.
Nobody is taxing humans the way cars are taxed, so why should the computing speed of a GPU be compared to that of a human?
> A bridge can hold ten thousand humans or thousand trucks. You can argue that a "human" may not weigh 100 kgs or a truck may not weigh exactly 1 ton. That's fine. It is a rough approximate to equalize unequal entities.
And you do not think that comparing weights to measure bridge load makes a lot more sense than comparing FLOPS to determine learning of GPUs vs humans?
EDIT: Maybe let's just go back to the original point
> We need to define machine in terms of "human-power"... much the same as how we already define automobiles via "horse-power". A single NVIDIA GeForce RTX 3090 chip, for example, delivers roughly 35.58 teraflops of standard computing power (via 10,496 CUDA cores). That means 35.58 trillion calculations every second. In comparison, a mathematically trained human being, taking their time to solve a complex, multi-digit decimal division problem by hand takes roughly 100 to 120 seconds. That gives the human 0.01 flops. To match RTX 3090, you would need 3.56 quadrillion people working/learning in perfect sync. We can use a calculation similar to this to derive metrics on how much is being stolen for "learning/training" these models. The loot can be quantified.
So you want to compare the learning rate of a GPU to that of a human by comparing their respective FLOPS. Why would FLOPS be a valid proxy for learning ability in humans just because that works out in GPUs, if the way they learn is fundamentally different?
Is the effect of someone reading a copyrighted book dependent on how fast they are at doing math in their head?
Yes, that’s pretty much the function of bullet points, visually speaking.
Visual hierarchy is a thing and when you have 3 icons next to single lines, you by default expect the all to follow the same pattern, cratering the icon vertically next to multi line text breaks the established visual pattern.
Author even did some bad things such as expanding the circle radius way too outside the x-height so the emphasis lies strictly on the circle, when it should be on the line… but anyways.
> It is disputed whether the name Wi-Fi is short-form for 'Wireless Fidelity',[34] although the Wi-Fi Alliance did use the advertising slogan "The Standard for Wireless Fidelity" for a short time after the brand name was created,[31][35] referenced "the Wi-Fi (Wireless Fidelity) logo" in a white paper[33] and the Wi-Fi Alliance was also called the "Wireless Fidelity Alliance Inc." in some publications.[36] IEEE, a separate but related organization, has stated "WiFi is a short name for Wireless Fidelity" on their website.[37][38] The name Wi-Fi was partly chosen because it sounds similar to Hi-Fi, which consumers take to mean high fidelity or high quality. Interbrand hoped consumers would find the name catchy, and that they would assume this wireless protocol has high fidelity because of its name.[39]
So it’s not really safe to say it’s not meant to mean wireless fidelity, in fact it sounds pretty likely.
reply