4,481 karma · joined August 18, 2014
That said, I like having a this pointer explicitly passed as it is in C with ADTs. The functions that do not need a this pointer never accidentally have it passed from the developer forgetting to mark the function static or not wanting to rewrite all of the function accesses to use the :: operator.
In the Linux VFS for example, there are optimized functions for reading and writing, but if those are not implemented, a fallback to unoptimized functions is done at the call sites. Both sets are function pointers and you only need to implement one if I recall correctly.
As for abstract data types, they originated in Lisp, which also predates object oriented programming.
This technique predates object oriented programming. It is called an abstract data type or data abstraction. A key difference between data abstraction and object oriented programming is that you can leave functions unimplemented in your abstract data type while OOP requires that the functions always be implemented.
The sanest way to have optional functions in object oriented programming that occurs to me would be to have an additional class for each optional function and inherit each one you implement alongside your base class via multiple inheritance. Then you would need to check at runtime whether the object is an instance of the additional class before using an optional function. With an abstract data type, you would just be do a simple NULL check to see if the function pointer is present before using it.
Permanent burn-in will happen with static images, but it happened on CRTs too and those once dominated the world. As long as it is infrequent, it is probably not much of an issue. Newer OLEDs, such as Apple’s tandem OLEDs, minimize the issue.
I am not sure what you think your point about black levels contributes to the discussion. Higher black levels would only favor OLEDs thanks to their inky blacks.
https://www.electronicsweekly.com/news/business/finance/arm-...
It is very unlikely Apple uses anything from ARM’s core designs, since that would require paying an additional license fee and Apple was able to design superior cores using its architectural license.
https://www.crowdstrike.com/en-us/blog/crowdstrike-supports-...
They happily implement a userland version on macOS, but then claimed that being in the kernel is absolutely necessary on Windows after they disabled all Windows machines using it.
There are different kinds of transistors that can be used when making chips. There are slow, but efficient transistors and fast, but leaky transistors. Getting an efficient design is a balancing act where you limit use of the fast transistors to only the most performance critical areas. AMD historically has more liberally used these high performance leaky transistors, which enabled it to reach some of the highest clock frequencies in the industry. Apple on the other hand designed for power efficiency first, so its use of such transistors was far more conservative. Rather than use faster transistors, Apple would restrict itself to the slower transistors, but use more of them, resulting in wider core designs that have higher IPC and matched the performance of some of the best AMD designs while using less power. AMD recently adopted some of Apple’s restraint when designing the Zen 5c variant of its architecture, but it is just a modification of a design that was designed for significant use of leaky transistors for high clock speeds:
https://www.tomshardware.com/pc-components/cpus/amd-dishes-m...
The resulting clock speeds of the M4 and the Ryzen AI 340 are surprisingly similar, with the M4 at 4.4GHz and the Ryzen AI 340 at 4.8GHz. That said, the same chip is used in the Ryzen AI 350 that reaches 5.0GHz.
There is also the memory used. Apple uses LPDDR5X on the M4, which runs at lower voltages and has tweaks that sacrifice latency to an extent for a big savings in power. It also is soldered on/close to the CPU/SoC for a reduction needed in power to transmit data to/from the CPU. AMD uses either LPDDR5X or DDR5. I have not kept track of the difference in power usage between DDR versions and their LP variants, but expect the memory to use at least half the power if not less. Memory in many machines can use 5W or more just at idle, so cutting memory power usage can make a big impact.
Additionally, x86 has a decode penalty compared to other architectures. It is often stated that this is negligible, but those statements began during the P4 era when a single core used ~100W where a ~1W power draw for the decoder really was negligible. Fast forward to today where x86 is more complex than ever and people want cores to use 1W or less, the decode penalty is more relevant. ARM, using fixed length instructions and having a fraction of the instructions, uses less power to decode its instructions, since its decoder is simpler. To those who feel compelled to reply to repeat the mantra that this is negligible, please reread what I wrote about it being negligible when cores use 100W each and how the instruction set is more complex now. Let’s say that the instruction decoder uses 250mW for x86 and 50mW for ARM. That 200mW difference is not negligible when you want sub-1W core energy usage. It is at least 20% of the power available to the core. It does become negligible when your cores are each drawing 10W like in AMD’s desktops.
Apple also has taken the design choice of designing its own NAND flash controller and integrating it into its SoC, which provides further power savings by eliminating some of the power overhead associated with an external NAND flash controller. Being integrated into the SoC means that there is no need to waste power on enabling the signals to travel very far, which gives energy savings, versus more standard designs that assume a long distance over a PCB needs to be supported.
Finally, Apple implemented an innovation for timer coalescing in Mavericks that made a fairly big impact:
https://www.imore.com/mavericks-preview-timer-coalescing
On Linux, coalescing is achieved by adding a default 50ms slack to traditional Unix timers. This can be changed, but I have never seen anyone actually do that:
https://man7.org/linux/man-pages/man2/pr_set_timerslack.2con...
That was done to retroactively support coalescing in UNIX/Linux APIs that did not support it (which were all of them). However, Apple made its own new API for event handling called grand central dispatch that exposed coalescing in a very obvious way via the leeway parameter while leaving the UNIX/BSD APIs untouched, and this is now the preferred way of doing event handling on MacOS:
https://developer.apple.com/documentation/dispatch/1385606-d...
Thus, a developer of a background service on MacOS that can tolerate long delays could easily set the slack to multiple seconds, which would essentially guarantee it would be coalesced with some other timer, while a developer of a similar service on Linux, could, but probably will not, since the scheduler slack is something that the developer would need to go out of his way to modify, rather than something in his face like the leeway parameter is with Apple’s API. I did check how this works on Windows. Windows supports a similar per timer delay via SetCoalescableTimer(), but the developer would need to opt into this by using it in place of SetTimer() and it is not clear there is much incentive to use it. To circle back not Chrome, it uses libevent, which uses the BSD kqueue on MacOS. As far as I know, kqueue does not take advantage of timer coalescing on macOS, so the mavericks changes would not benefit chrome very much and the improvements that do benefit chrome are elsewhere. However, I thought that the timer coalescing stuff was worthwhile to mention given that it applies to many other things on MacOS.
By the way, when I wrote in another comment that bufferbloat was solved, I meant it in the same way that IPv4 exhaustion is solved by IPv6. We have the ability to deploy solutions that largely fix things, but whether we do is another matter. You are right to say that the past 10-15 years have started to make a dent in the problem. I had not meant to suggest otherwise.
This is the most bizarre choice of “hill to die on” that I have ever seen.
I will point out that you were not interested in debating in good faith, as your sole purpose is to make the point that people should treat buffer bloat as a theoretical issue that does not actually affect people, with the explanation for every incident of buffer bloat always being something else. Everything you wrote has been consistent with that. You even applied a pattern of overanalysis to the discussion that can be used to claim the contrary to anything. Your apparent need to deny the existence of a well known issue is bizarre. You would be much happier right now if you had dropped the subject.
By the way, peering links between the greater China area and the rest of the world are notoriously bad due to limited capacity. China in particular has three tier 1 networks that all refuse to upgrade peering links between each other in a timely manner, and the peering links between them and the rest of the world are often just as bad as the peering links inside of China. In order to get a decent connection there in 2016, I had to forcibly do my own routing through VMs in data centers in Shanghai, Tokyo and others to control the links used, after much trial and error, yet there were still periods where the links were horrendous and surprisingly, the issue was not always exclusive to China according to my testing between VMs on various data centers. I was visiting family for a month, yet needed a decent connection to work remotely, so I spent an entire week non-stop studying the connectivity and experimenting with ways of improving my VPN connectivity. I also had proof that the GFW was not where problems occurred, since my tcpdump pcap files taken at VMs in Shanghai and Tokyo showed the packets traversing the GFW. I also had reproduced similar performance issues using VMs in other countries, such as Japan and Singapore, where there is no GFW, as part of attempts to identify paths over which I could forcibly route my traffic via iptables rules. It is obvious to me that you will continue to deny bufferbloat was a problem and instead blame something else, yet as others have already explained to you, bufferbloat makes problems worse. After a delay of a few hundred ms, my VoIP session did not care if the packets were delivered or not, since at that point, the packets were useless, yet enormous buffers would delay them and other traffic well past a sane expiry instead of dropping it, to the detriment of all trying to use the peering links.
Historically and likely still in the present day (but not in my household as we use AQM now), whenever one person in a household does a large download, internet latencies shoot up for everyone in the household, which is also bufferbloat. Having to wait hundreds of ms per round trip brings us back to the 56k dialup days and the performance impact on interactive traffic is horrific. It is enough to make VoIP unusable. As others have told you, there can be other issues at the same time, but bufferbloat makes the issues worse. I cannot speak for others on the extent to which they are afflicted by buffer bloat, but adopting AQM had a night and day difference in performance of the internet connection in my house, since I often do big data transfers that previously would slow down basic web browsing for everyone in my house, myself included.
As for your conjecture that extant problems are visible in recent journal publications, journals have a selection bias. The idea that a problem’s existence is indicated by the degree to which people are publishing papers on it in journals is fallacious since the papers need to not just provide something new, but also be interesting to those running the journal (i.e. make them think that the papers would elevate the status if their journal and help them get increased readership, provided that they are not a junk journal that will publish literally anything). On top of that, the work needs to be funded. Bufferbloat, which is largely considered a solved problem and which predominantly affects the less affluent these days, is not something that will get much attention in journals since nobody in academia seeks funding for something that they do not think they can improve or publish.
Finally, I did not use any ad hominem remarks toward you, as my remarks had focused entirely on what you wrote. I did write that any further replies would likely be done to get you to keep talking so I can play my old game of “figure out what is wrong with someone posting bizarre things on the internet”. About 30% of the population is mentally ill and thus when someone is posting bizarre things online, it is often the result of mental illness. Figuring out which mental illness is often the only reason responding to bizarre posts is worthwhile (as it is both an intellectual challenge and a public service). This contradicts your remarks suggesting that there is no point to my replies, to use my words rather than yours. It is not an ad hominem remark to say that I am likely to do this analysis. Posting the results of the analysis would be, but it would be grounded in fact and would likely be done to suggest professional help for X condition, if my amateur analysis identifies a condition that could benefit from professional help. Honestly, I think the world would be a better place if more people who studied psychology (even 1 class like I did) played armchair psychologist when others persist in a pattern of bizarre remarks and refer those who need professional help to trained professionals.
I was being generous by advising you to stop posting, since the more you post asinine things, the worse you look. In the past, I have taken the liberty to do amateur psychoanalysis of people who post bizarre things online based on a psychology class I took in college. If I keep responding, it will only be to get you to post more so that I can work out what is wrong with you for my own curiosity. I am probably not the only one thinking this.
The worst that I have ever seen was about 30 seconds when visiting a foreign country where bufferbloat was occurring at peering links. The bufferbloat in peering links is likely visible from western countries if you ping residential IPs in developing countries and monitor the ping times over days. Some parts of the day will have very high ping times while others will not. The high ping times will be the buffer bloat.
In most western countries, the bufferbloat typically occurs at people’s home internet connections. As is the case in all cases of buffer bloat, the solution is to be willing to drop packets when the connection is saturated. If you limit the bandwidth just below what the connection can handle, you can do active queue management to solve the problem.
That said, I suggest you stop posting replies. Your crusade against the idea of buffer bloat makes you look bad to anyone with enough networking knowledge to understand what bufferbloat is. I also strongly suspect I wrote an explanation that you will take zero time to understand and rather than take my advice, you will post another reply to continue your crusade. :/
https://en.wikipedia.org/wiki/Eastman_Chemical_Company
One really must admire their determination to throw all of the life boats overboard to go down with the film ship. Every time they have a chance to save themselves if they move away from a single minded focus on film, they discard the opportunity. They just needed to mimic Nikon and Canon to stay in business, but refused to do even that.
The only way I see Kodak having a happy ending would be if Eastman Chemical purchases their former parent company to put it under sane management.
That said, every LLM has its quirks. For example, Gemini 1.5 Pro and related LLMs have a quirk where if you tolerate a single ellipsis in the output, the output will progressively gain ellipses until every few words is followed by an ellipsis and responses to prompts asking it to stop outputting ellipses includes ellipses anyway. :/
“Malicious compliance” is the act of following instructions in a way that is contrary to the intent. The word malicious is part of the term. Whether a thing is malicious by exercising malicious compliance is tangential to whether it has exercised malicious compliance.
That said, I have gotten good results with my addendum to my prompts to account for malicious compliance. I wonder if your comment Is due to some psychological need to avoid the appearance of personification of a machine. I further wonder if you are one of the people who are upset if I say “the machine is thinking” about a LLM still in prompt processing, but had no problems with “the machine is thinking” when waiting for a DOS machine to respond to a command in the 90s. This recent outrage over personifying machines since LLMs came onto the scene is several decades late considering that we have been personifying machines in our speech since the first electronic computers in the 1940s.
By the way, if you actually try what you suggested, you will find that the LLM will enter a Laurel and Hardy routine with you, where it will repeatedly make the mistake for you to correct. I have experienced this firsthand so many times that I have learned to preempt the behavior by telling the LLM not to maliciously comply at the beginning when I tell it what not to do.
1. It is non-trivial additional work to add since these are high frequency signals.
2. It is non-trivial additional work to validate.
3. The hardware PCI-E support is likely buggy because it is not well tested and few want to volunteer to spend time working with the SoC supplier on the bugs.
1. A closed system cannot exhaust heat via evaporative cooling, which would defeat the purpose.
2. Many datacenters are no where near salt water.
3. There are likely reliability issues that would need to be overcome and it is simply cheaper to use fresh water.
I have only ever toured a data center once, but the one I toured had no water usage by the cooling infrastructure as far as I could tell. However, the facility’s APUE was something like 1.7, which is high. I have read that some facilities with impressively low APUE numbers use water during particularly hot summer days, which is presumably for evaporative cooling. Unfortunately, I have yet to see one of these facilities in person to know the details beyond what has been publicly written.
If it counts for anything, I have hundreds of commits in OpenZFS. I know some things about data centers from a mix of professional contacts since my work is used in them (which is how I got the tour in the first place), and personal interest in the subject, but I am far from an expert on all aspects of how data centers work. Speaking of which, I doubt there is any one person who is an expert on all aspects of how data centers work, since the knowledge is spread across multiple types of experts. A physicist would not be my first choice of expert when asking questions about data centers. A data center technician would be a better person to ask.
My household (in the US) uses water from cooking rice to water plants, but I cannot imagine many UK households cook rice to be able to do that.
I would have speculated that they are imagining savings opportunities that do not exist, but the “delete emails” advice gives clear evidence that they are imagining savings opportunities that do not exist, so there is no need for speculation.