Hacker Newsnew | past | comments | ask | show | jobs | submit | Scubabear68's commentslogin

My personal take is a pre-requisite of true human-like AI is physical feedback and a concept of emotions or something like it.

Without physical feedback you can rapidly devolve into unstable positive feedback loops. And emotions are what help us process and react to that feedback.

Kids learn partially because their friends say sharp words that hurt them, fire burns them, they go hungry and starve if they don’t plan for meals.

Humans in the loop, MCP, etc are all very primitive hacks that are mimicing feedback and emotion, poorly.


Emotional constructs are not necessary for AI, and LLM are not "AI"... even though some people incorrectly equate conceptual compaction with thought-process.

Most human daily life runs on habitual scripted behavior, and that is even true within online parasocial interactions. It is why people often continue to shop in the middle of a violent robbery, and why LLM predictive text sounds rational when we project social norms on plagiarized conversational structures gleaned from other users.

Neuromorphic computing may bring about viable AI in the future, but our current LLM trajectory would require >63% of our galaxy energy output to reach a single human-level error rate.

LLM are fairly good at some tasks like context search, but people will need to recognize the Gartner Hype Cycle "Peak of Inflated Expectations" stage eventually. =3

https://en.wikipedia.org/wiki/Gartner_hype_cycle


> My personal take is a pre-requisite of true human-like AI is physical feedback and a concept of emotions or something like it.

Ted Chiang's recent article, which received a lot of pushback from HN'ers (but not from me, I agree with Chiang) claimed for true consciousness the AI needs a physical body, and emotions (which means organs and hormones and a system capable of feeling emotions). I would also add that to behave more rationally, it should have a real sense -- not a roleplayed one -- of self-preservation and a notion that bad choices can lead to an end to its existence.


Needs 2019 in title, this is Intel MacBooks not Apple Silicon.


I've found that Baldur's Gate 3 will warm up my apple silicon (everyday tasks do not).


Is that running on Rosetta 2? Rosetta 2 does (or did, maybe it's removed now) a fine job running x86 code on Apple Silicon, but boy was it cycle-hungry to do it.


Apple Silicon is not really the simultaneously silent and quiet and cool system it was in the M1 days.

If you get a MacBook Air it will get quite toasty at throttling limits. After all, it has no fan.

MacBook Pro models and Apple computers in general tend to favor quiet operation over keeping the laptop surface cool.

Many PC gaming laptops go out of their way to keep warm air off the keyboard deck with a high willingness to use fan noise to accomplish that since the assumption is that you’re resting your hands on the computer for an extended period and you have headphones on for your game anyway.


I probably should have clarified that I'm on an M1 then (a macbook pro, so there is a fan). I didn't realize the newer ones get warmer.


BG3 is a native game, they dropped x86 support shortly after launch on macOS (or maybe even in beta)


[flagged]


The target market of the "Neo crap" doesn't care and/or isn't pushing workloads that come anywhere near saturating it. It's a laptop that doesn't bend, has a decent screen, has a decent battery, and isn't full of adware.


The article was about warming up a laptop. Neo can do it too.


And your comment was calling it crap for some reason. We wouldn’t be having this conversation if you’d left that apparently superfluous word out of your comment.


How does the Neo getting to 100°C make it crap? By that logic, aren't all older Intel/x86 chips crap? If anything, I find it impressive that a small laptop CPU can do 100°C without a problem...my i7-7700T M710qs hit 75°C and throttle within a minute if I use a tool like y-cruncher or stress-ng. To be fair, totally different purpose.


For a very long time now, it has been the case that in the short term most processors will boost high enough for the die to reach around 100°C. When you see a reading substantially lower than that like your example of 75°C, either the system has throttled for a reason other than processor die temperature (eg. throttling to limit the temperature of the outer case of the machine) or the temperature reading you're seeing does not correspond to the hottest part of the chip and the throttling is based on the presumption that a different part of the chip that is not directly monitored will be much hotter.

In the specific case of the i7-7700T, the "T" suffix for Intel CPUs usually means you have mainstream desktop silicon with arbitrarily reduced long-term turbo limits, intended to be used in small form factor PCs with limited cooling capacity. Its limitation to 35W sustained and official Tj max of 80°C are artificial and essentially fiction, and the same silicon will readily do 91W sustained with a Tj max of 100°C as seen on the i7-7700K.

Processor temperature under load tells you almost nothing about the power draw or efficiency of the chip, because the temperature can be controlled to almost any value desired through a combination of varying cooling effort and varying clock speeds.


Curious about the T case - is Intel doing some kind of binning and trying to select the processors most likely to fail under high thermal load to assign that suffix to? And thus the T procs are priced lower?


I am not surprised, but disappointed, to see something like the CHIPS Act be used for something which is still in ultra-super-unbelievably-early-research-phase. Put more candidly, something not currently useful like Quantum computing.

Looks like just a handout to IBM.


The administration fired the original CHIPs Act team and so the new team might not be up to speed.


I have been using an 8GB Macbook Air M1 for non-development work, and it has been fantastic.

Macos really excels at managing memory very well.


I used an M1 Air for developing iPhone Apps for years and it worked great. Not "wow" fast but I never had a complaint about it.


Heck, on Windows it would be 4GB if you're lucky.


I went to Holmdel High and my girlfriend's dad was an engineer at the Bell Labs Holmdel location. As it turns out he invented a little something called Adaptive Delta Modulation (aka Abate Delta Modulation) for his Doctorate Thesis in 1968.

They definitely had brain power at the Holmdel location too.


"AI coders submitting 25 PRs within an hour of an issue being filed, GitHub bears the brunt of that....".

What "brunt"? These are not large numbers.


Before AI coding, a GitHub issue might get one or two PRs after six months.

AI coding has made this orders of magnitude bigger.

The individual numbers are small, but they add up quickly.


Maybe I am really dense, but a single issue getting 2 vs 25 PRs seems to be no practical difference.


Well two in six months vs 25 in one hour. So that's a 54,000x increase.

But also, each PR kicks off a bunch of CI work, often in GitHub Actions.


Precisely.

If Microsoft can't scale something like Git 14x, then the problem is with Microsoft.


I really don't understand people saying that this is due to AI commits and it is all the volume's fault.

A volume increase that is a single order of magnitude (which 14x is) should not result in this level of failures.

When I compare what Github does and the volumes vs social media companies, payment companies, video platforms, etc, it just doesn't make sense that it is just a volume problem.

It looks a lot more like a platform that already has baseline issues that are compounded by increased volume.


What happens at your job if there's suddenly 14 times as much load?


> What happens at your job if there's suddenly 14 times as much load?

You mean like every startup ever that has been successful?

And for a service that is heavily text bound? A 14x increase would not be a big deal.


My roommate circa 1989 had a bunch of Apple II’s with multiple modem cards per machine to run a bulletin board. Not sure why an Apple II could support multiple users logging into the BBS via multiple modems but DOS based machines could not.


A function call is not necessarily an indirection. Basic premise of the blog is wrong on its face.


1. "Indirection" can be logical, or runtime.

2. Please read the blog. That's literally what is said.


Did you read the article? The author makes exactly that point.


[flagged]


Why do you mention lifetimes here? They are exclusively a compile-time pointer annotation, they have no runtime behavior, thus no overhead.

Dynamic dispatch in general is much, much faster than many people’s intuition seems to indicate. Your function doesn’t have to be going much at all for the difference to become irrelevant. Where it matters is for inlining.

Dynamic dispatch in Rust is expected to be very slightly faster than in C++ (due to one fewer indirections, because Rust uses fat pointers instead of an object prefix).


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: