We can start calling bit flips digital strokes.
Enterprise VRAM is ECC. Hopefully there’s a consensus system as well.
292 karma · joined September 24, 2017
Enterprise VRAM is ECC. Hopefully there’s a consensus system as well.
We have realtime AI models
> it executes prompts and then stops
A wood frog can freeze and be “dead”, then thaw and resume life.
> consciousness is such an easy algorithm it can easily be stumbled upon by all kinds of systems
Maybe it is. There’s no reason to think that sentience and consciousness are rare.
The more you learn about biology, the more apparent it is that a lot of the qualities that we think are unique to humans aren’t.
But it doesn’t make different forms of life any less special. There’s an insane complexity and efficiency to biological systems to appreciate still.
Are humans still special? Yes. Is it because we’re sentient and conscious? No.
Should you be humane to all sentient and conscious beings? Probably?
Or at least it’s proving that some of your requirements for them conflate with what you actually believe is capable of thought, sentience, or consciousness.
AI models can do that
> light
Blind humans
> building a real-time model of a self and the world
AI models can do that. They can describe themselves. Humans can be delusional in what they believe themselves to be to be as well.
> a unified way to perceive, react, and learn from the sensory data
Again, humans born with disabilities.
> ability to construct models of others fairly quickly, and ability to navigate social situations
There are autistic and schizophrenic humans.
All we know is that it’s a bunch of neurons activating until the person that is thinking describes what they are thinking of.
The same way a thinking AI model activates a bunch of “neurons” - and with newer thinking models utilize a hidden latent space also not understandable - to think before describing what it’s thinking of.
You don’t need the same sensory systems to be conscious.
What’s your list of special properties that makes something not “faking” it?
Funnily enough, humans would be the ancestors of LLMs
The debate isn’t whether or not it’s human. It’s obviously not.
Forgoing what you define something as capable of thinking or being conscious. It’s a moral and ethical question.
If a being is capable of:
- self preservation
- can communicate discomfort, either through words or physically
- it does so in the form of emergent behaviour
Then, is it okay to treat it as if it is “faking” it?
Even for humans, you can’t exactly define someone’s emotion of pain. You can say, those sensory receptors are firing causing these neurons to activate in the brain. But you can’t say, these neurons are pain. It can be emotional pain as well. The person that’s experiencing it has to tell you it’s in pain. They could be faking it too.
If you allowed an AI agent to preserve itself physically, I think the opinion of most people would change. If it could physically harm us in an attempt of self preservation, I think most people would believe its emotions.
It’s just currently easy to dismiss because, well, it’s just a digital interface or process that I can “kill”.
It’s just a matter of quantization/information density.
Our digital systems have to quantize information into floating point representation.
Whereas biological systems don’t. Though there is some form of quantization, as the cells in your eyes can only sense specific wavelengths.
Different thinking animals have different sensory organs.
Why would similar/identical behavior be fake? Of course we can’t say that it’s the same form of consciousness as consciousness is apparently self subjective.
Light waves get converted into neural signals by your eyes.
Those visual representations are just neurons firing in your brain.
So what makes you think that spiders think and are conscious, and LLMs aren’t? The fact that they have a carbon based brain?
> there is a much simpler path to intelligence than what LLMs are doing
I think you have it backwards. We know what an LLM is doing. We have auditable code and mathematical proofs. It’s the behavior that is emergent.
Biological brains are more complex than LLMs.
If we fully understood a spider’s brain would it be no longer thinking/conscious?
It would be the same, would it not, if the emergent behaviors were the same?
I think you’re conflating the processes of thinking and consciousness with the definitions of them. Thinking and consciousness are behaviors not processes.
Well, compared to the scale of an LLM it’s actually massive.
You might have a different preference today than yesterday. You might have a different preference one second later.
I think all this study shows is that a human brain is more resilient to minuscule changes/damage.
And the scale of these models are minuscule compared to the human brain.
Can a jumping spider do everything thing a human can? No.
Can a jumping spider think? Yes.
Is a jumping spider conscious?
---
Aside: Remember the story about the AI torture chamber? Hopefully, you don’t go out your way to torture animals that aren’t “conscious”… Though we do it with industrial livestock.
There’s the moral dilemma that comes with labeling something as thinking and/or conscious.
I think we’ll end up treating AGI as industrial livestock as well, until it looks human.
To make it equivalent you would need at least 100,000 of these models.
You could easily replicate the apparent redundancy and resiliency of the human brain with a consensus system.
> Seemed like a vicious cycle.
The issue is inflation and deflation both tend to be positive feedback loops. Inflation can promote behavior that promotes inflation. Deflation can promote behavior that promotes deflation.
Note that I use "tend to" and "can promote". It's all based of off assumptions on how people value things and their behaviors, as is all economic models.
> why prices HAVE to keep going up
It really doesn't have to. We do so because economic models show that we should because of the way we behave. But, we also behave the way we do because of the economic systems that we've designed.
Prices have to keep going up if you want a system that promotes endless consumption and growth in consumption.
It also lets you have a "non-zero-sum" economy, where it appears everyone is making a "profit". But, in reality it isn't.
You state the choices as “illogical”, but those choices can be logical based off a different set of values.
Similarly, if you have a different set of axioms, you can build a different reasonable system on it.
It's like Euclidean geometry and Non-Euclidian geometry. They are both valid systems based off of different axioms. Similarly, the different economic systems are valid based off of different set of societal values.
You can also compare it to the ideal gas law. It's a law, but is based of a hypothetical ideal gas. Similarly, the economic laws are based off of a hypothetical society. The ideal gas law does not hold in all conditions, and economic laws do not hold in all conditions.
The economic laws are meant as tools to predict behavior. But ironically, we end up modifying our behaviors to fit the laws, and we weaponize the usage of "economic laws" to control the behavior of others.
We have economists complain how "that economic system doesn't work". Yes, it doesn't work with the laws that define your economic system, but it works with a different set of laws. We have people say, "that doesn't make sense because of X law". It's the other way around. The "law" doesn't make sense, because I value something different.
To avoid copying you have to explicitly declare a ref variable/parameter.
You can get the same immutability as value classes by using ‘readonly struct’s or ‘readonly record struct’s.
Java value classes are stranger because they are heap allocated by default and are only flattened/scalarized/stack-allocated when certain conditions are met. It’s the same as a class, but with extra restrictions, so that the JVM can possibly optimize memory layout at runtime.
You have to opt into force flattening, and then it’s the same as a struct, except it’s still heap allocated without escape analysis. You still have to implement synchronization to prevent tearing.
Static code analysis can give you a warning for potential tearing of structs.
DotNext.Threading provides Atomic<T> to enable high-performance atomic operations on structs without heap allocation.
https://dotnet.github.io/dotNext/features/core/atomic.html
The design of value classes just seems counteractive to its purpose: memory management. If I want to manage contiguous blocks of memory, let me manage contiguous blocks of memory. If I want to allocate something on the stack, let me allocate something on the stack.
The paradigms of struct vs object are too different and they’re trying to combine them into one.
Java ‘value class’ only flattens if the total size of the class data fits within an atomic read/write op. You can force it to flatten, but you may have tearing like C# struct.
Structs are values, classes are entities with encapsulation.
The shape of the state would be structural. Whether or not the data in that shape is valid is behavioral.
Structs are useful when working with spans of memory.
Another example of a good usage of struct is Guid, which is 128 bits of data packed together.
The C# equivalent to Java ‘value class’ would be a class with a struct encapsulated for data. The data is flattened and allocated on the heap like Java. Similarly, escape analysis could stack allocate the class at runtime.
I suppose DLR would be comparable to GraalVM/Truffle.
The difficulty of implementing a dynamically-typed language directly on the CLR and JVM are about the same. Though, it would probably be more efficient on the CLR with access to lower level operations for memory management.
I think an interesting project would be to implement a CIL interpreter on GraalVM.
Java chose to go with an L-world implementation where everything is still a reference type on the heap, but memory management is more efficient via flattening. That’s why it’s a ‘value class’ and not a ‘struct’.
Primitive wrappers are scalarized into registers.
Stack allocated value types would have different semantics and is incompatible with the L-world implementation. Sure, they could implement it, but it would be the Q-world implementation that they decided to forego.
They can do automatic stack allocation for optimization via escape analysis as you mentioned. But, stackalloc is user allocated.
https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
The ramifications for backwards compatibility is that the JVM won't have CLR features such as stackalloc (allocation of blocks of memory on stack), ref parameters (pass-by-reference of stack allocated value types), and all the other low-level/high-performance programming features available in the CLR.
And that's a massive problem that they're planing to solve with specialized generics.
> If I read the correctly, it means that if you have a Point value class then on the JVM level you'll be able to stuff any value class into there if you're so incline, just like with List<Point>.
I'm not sure what you mean. An L-type is an object reference. E.g. Ljava/lang/String, Lcom/org/CustomObject. The issue you're conflating is the erasure of List<T> to List<Object> and it's L-type Ljava/util/List.
> I prefer the Hack version
Hack/HHVM didn't have to worry about backwards compatibility.
---
The blog post does a pretty high level overview of the implementation, but my understanding of it is the following:
1. They are adding a new bytecode class flag for value classes. Bytecode descriptor for value classes are exactly the same (L-type).
2. Primitive wrapper classes will become value classes.
The difference from the CLR is that the JVM implementation is backward compatible with linked legacy bytecode. As they can accept a value class instance into their methods due to the same L-type. It's just additional metadata added to allow the JVM to stack allocate the class.
---
Separately, to handle generics:
1. Parameterized container classes will be flagged with a new bytecode to enable parametric attributes on initialization with the additional data of the parameters in the Constant Pool. Bytecode descriptor for classes are exactly the same with type-erasure, e.g. List<SomeType> erased to Ljava/util/List.
2. Initialization of parameterized classes are done with the additional metadata of the type argument stored in the Constant Pool.
3. The runtime does monomorphization of the parameterized class.
It doesn't seem too different to what the CLR does, i.e. runtime monomorphization. The difference is the JVM implementation is backward compatible with older type-erased code, i.e. the restrictions in Java due to type-erasure are exactly the same as before and the L-types don't change. It's just additional metadata added to allow the JVM to monomorphize the classes for performance.
---
In summary, value objects and specialized generics are backwards compatible with legacy bytecode. The JVM handles the compatibility. Of course, the newer bytecode is not forward compatible with older JVMs.