My point is really that there is no need fo greater sjngle-package processing power except the reduction of package size, which is all a marketing goal.
Making the package smaller raises the power density and increases the internal temperature, reducing the reliability. It also makes any system more difficult to service, thus increasing the amount of electronic waste materials.
So really, the results are simply not worth the effort.
A much greater gain in performance would come from more efficient code. But creating more efficient code will require levels of both skill and talent presently not available.

This isn't quite true. Cores sharing a die potentially have much higher bandwidth communicating with each other than package-to-package connections. For parallelized processes this can mean considerably more throughput.

Reduction in package size also has practical implications for portable, implantable, wearable, and otherwise embedded devices. When you are trying to make things like smart watches, smart glasses, medical implants, and the like, package size is completely relevant. Tiny packages with low voltage, high efficiency processors are an enabling technology.

 

The simpler explanation comes from the way surface area and volume play out in the race to dissipate heat. The larger the volume and lower the surface area, the harder it is to get the heat out of the package. Surface area plays a big role, because that is the only way out for the heat. Volume plays a role because we try to pack as much as we can into one volume, and the more we pack the more heat we generate internally, and it could also mean a longer distance for the heat to travel to the surface. The ideal shape I think would be a sphere.
Everything else is about ingenuity, but there is no way to beat the surface area problem. Even if we use liquid nitrogen, we still reach a limit although it would be much higher than what we see with water cooling.

Funny how nature (or some creator) has already solved this problem -- including the manufacture of such: self-replicating, self-growing, self-learning.

Seems we have a ways to go.

 

Seems we have a ways to go.

Further thoughts:

A primitive bacterium has enough computing power (and associated hardware) to guarantee its survival through perpetuity, all self-contained in a package a few hundred nanometers in size.

Is there anything we have created that comes even close to this?

I'd say Moore's Law is not dead yet. Perhaps, just taking a nap.

 

To be clear .
Tong well and truelly in cheek when said ai ..
But thinking about it more.
Compilers are great ,but code still seems to bloat over time .
Wonder what tool could help fix that and could it be ai ?

Code bloat is a trivial problem that can mainly be solved by mechanical means if indeed that was the 'Wall'.
https://en.wikipedia.org/wiki/Amdahl's_law

An implication of Amdahl's law is that to speed up real applications which have both serial and parallel portions, heterogeneous computing techniques are required.[5] There are novel speedup and energy consumption models based on a more general representation of heterogeneity, referred to as the normal form heterogeneity, that support a wide range of heterogeneous many-core architectures. These modelling methods aim to predict system power efficiency and performance ranges, and facilitates research and development at the hardware and system software levels.[6][7]

It's the lack of depth of problem expression that seems to be the issue IMO. There is some, maybe still be be discovered, 'Calculus" that's needed we just don't have and can't create with current computing machine theory or application. That issue spans the range from fundamental hardware logic design to most complex neural network language deep learning models. It was hoped that the 'self-learning' methods of programming machines without human coding would somehow breach this 'Wall' but it really hasn't happened.
https://www.formica.ai/blog/which-ai-is-learn-by-its-own

All we've really done so far is to create poor cartoon creations of cartoons using billions of tiny nanometer sized hammers, not the actual thing.

 

Hello again,

What we really need is a way to create transistors that do not dissipate any heat. Not sure if that is possible though.
The light operated transistors are supposed to be better due to their operation with light not electrical current, but there are problems that come up with the implementations.
We just have to wait for technology to improve i guess.

We could probably estimate the limits that are obtainable given the best materials and best manufacturing processes presently available today.

BTW, humans are limited due to surface area also, as are other living things.

 

What we really need is a way to create transistors that do not dissipate any heat.

Thermodynamically, this is impossible. It's an entropy thing. You could theoretically create a transistor that doesn't dissipate heat, but it would not be able to do anything.

The trick is continued improvements in power dissipation vs. quantity of performed work. I think the limit is near what biological systems (i.e "wetware") have achieved, thus my posts above.

Edit: Oh, and we're not going to get there with silicon or lasers.

 

BTW, humans are limited due to surface area also, as are other living things.

I used the most primitive bacterium a few posts ago to illustrate how far we are from reaching these limits.

Has anyone devised a machine that can successfully hit against a MLB pitcher?

Edit: No.

I don't think so. But a human (well, a small fraction of them) can do so with only 3 Lbs. of CPU and a ham sandwich.

 

I believe that TSMC has the ability to stack chips inside one package.

Yep. This is pretty common, not just TSMC. Many modern processors are not single chips, but rather multi-chip modules. A big reason for this is because different parts of the processor are better done with different processes.

There are also other chips, such as neural net chips and memory, that are not general purpose processors but that lend themselves to very tightly-packed, array-oriented cell layouts that allow huge numbers of transistors to be fabbed on a single die.

So, especially when trying to place where we are relative to Moore's Law, it has gotten tricky because it's hard to compare apples to apples.

 

To be clear .
Tong well and truelly in cheek when said ai ..
But thinking about it more.
Compilers are great ,but code still seems to bloat over time .
Wonder what tool could help fix that and could it be ai ?

Code bloats largely because there is no real penalty associated with the bloat, but there is a huge advantage to being able to develop code quickly and get it to market.

Another big source of code bloat, which is tightly tied to the "develop code quickly" is the reuse of high-level data structures and objects that have powerful features. It is very rare that any given application needs all those features, but if umpteen different applications all use the same object, then the time to develop and vet that object can be justified. Then the object can be used quickly and effectively by software engineers and programmers that lack the knowledge and skill to actually understand it, let alone design and implement a more tightly-matched object to their actual needs.

As long as the speed and memory keep growing fast enough, the impact of all of that bloat is hidden and not a factor of any consequence.

When you consider the amazing things that were accomplished with the tiny amounts of processing power and memory back in the early days, it's tempting to try to imagine what kinds of applications could be achieved with modern hardware if only the software were written with that same degree of efficiency. But that neglects to take into account that developing code at that scale with that same degree of efficiency may simply be intractable.

 

Code bloats largely because there is no real penalty associated with the bloat, but there is a huge advantage to being able to develop code quickly and get it to market.

Another big source of code bloat, which is tightly tied to the "develop code quickly" is the reuse of high-level data structures and objects that have powerful features. It is very rare that any given application needs all those features, but if umpteen different applications all use the same object, then the time to develop and vet that object can be justified. Then the object can be used quickly and effectively by software engineers and programmers that lack the knowledge and skill to actually understand it, let alone design and implement a more tightly-matched object to their actual needs.

As long as the speed and memory keep growing fast enough, the impact of all of that bloat is hidden and not a factor of any consequence.

When you consider the amazing things that were accomplished with the tiny amounts of processing power and memory back in the early days, it's tempting to try to imagine what kinds of applications could be achieved with modern hardware if only the software were written with that same degree of efficiency. But that neglects to take into account that developing code at that scale with that same degree of efficiency may simply be intractable.

Hi,

That's one of the reasons i hate Java. It's forced methodology using predeveloped code sections.

I did a lot of asm programming back in the day and that stuff is FAST. Too bad it's not anything near that now. It's actually stupid in some ways and i don't see any improvement in errors in code using the predeveloped stuff.

 

Thermodynamically, this is impossible. It's an entropy thing. You could theoretically create a transistor that doesn't dissipate heat, but it would not be able to do anything.

The trick is continued improvements in power dissipation vs. quantity of performed work. I think the limit is near what biological systems (i.e "wetware") have achieved, thus my posts above.

Edit: Oh, and we're not going to get there with silicon or lasers.

Hi,

Yes i am of course aware of that. Optics may improve on this with future developments, but of course it can never go away completely as it's almost like thinking about a 100 percent efficient machine. You just can't take anything out of it and expect it to still be 100 percent efficient. The trick is to get as close as possible to ideal. That's what i was talking about really. I think the problem with that is things have to get smaller and smaller, and unfortunately the ideal case would be an infinitely small thing which of course still can't do anything (almost laughable ... no wait, it is laughable ha ha).

 

I think the problem with that is things have to get smaller and smaller, and unfortunately the ideal case would be an infinitely small thing which of course still can't do anything...

Yet a single human cell contains all the machinery and code required to build a complete human.

Like I said, we ain't close to the limits!

 

I did a lot of asm programming back in the day and that stuff is FAST.

My TRS-80 boots faster than my fastest modern desktop with an NVME drive.

 

My TRS-80 boots faster than my fastest modern desktop with an NVME drive.

And it has all the same capabilities, right?

 

And it has all the same capabilities, right?

Eventually.

 

Yet a single human cell contains all the machinery and code required to build a complete human.

Like I said, we ain't close to the limits!

+1 We are so far from what's possible with the simplest forms of life with any projected advances in computers it should make a person wonder what we are missing in our basic understanding of life and intelligence. I'm not a religious person so I don't have faith in supernatural things like a soul but there is something far beyond our current understanding that I hope we will eventually Grok, otherwise we will remain just intelligent tool using apes forever.

 

...otherwise we will remain just intelligent tool using apes forever.

That sentence reads funny without the hyphen.

 

Code bloats largely because there is no real penalty associated with the bloat, but there is a huge advantage to being able to develop code quickly and get it to market.

Another big source of code bloat, which is tightly tied to the "develop code quickly" is the reuse of high-level data structures and objects that have powerful features. It is very rare that any given application needs all those features, but if umpteen different applications all use the same object, then the time to develop and vet that object can be justified. Then the object can be used quickly and effectively by software engineers and programmers that lack the knowledge and skill to actually understand it, let alone design and implement a more tightly-matched object to their actual needs.

As long as the speed and memory keep growing fast enough, the impact of all of that bloat is hidden and not a factor of any consequence.

When you consider the amazing things that were accomplished with the tiny amounts of processing power and memory back in the early days, it's tempting to try to imagine what kinds of applications could be achieved with modern hardware if only the software were written with that same degree of efficiency. But that neglects to take into account that developing code at that scale with that same degree of efficiency may simply be intractable.

So very correct!!
Code bloats both because there is no cost to the producers for inefficient software creation approaches. And I recall using the tester machines that had the 6809 processors with the kilohertz clocks, that booted from ROMs in seconds, and how very much faster they were than the behemoth testers that used the 30 megahertz clocks but ran windows.

But the other cause is feature bloat, where those folks unable to focus add every possible feature, no matter that this reduces both reliability and the product interface quality. Quite possibly only NASA has been able to reduce that problem. But that is a topic for another thread.

 

Responding to post #38: if there are suddenly a lot of solutions then the new problem is selecting the LEAST INCORRECT solution. And that explanation is either wrong or so generalized as to be useless.
Certainly it does not come close to answering what I was asking about. Consider that not all answers will have adequate value, now there is the challenge of somehow determining which is correct. A bit like using a checksum error to find which bit is incorrect.

Hi there,

The problem of errors is a different problem. Once a scheme for eliminating errors is developed there are no errors anymore and all the solutions, no matter how many, are all correct. If all the errors could not be eliminated, then that would be a problem too though.
For the example y=A*sin(w*t), we know that there is no error in that, and there is no error in Y=A.
There is still the problem of programming and picking out the solutions we want, which introduces that time lag which I don't think can be eliminated. This is equivalent to setting the input data into the quantum computer and getting the results out. The only solution may be that EVERYTHING has to exist inside the computer, or at least as much as possible and only take the output, when absolutely necessary, to the outside world.

 

My TRS-80 boots faster than my fastest modern desktop with an NVME drive.

Hi,

Wow that's amazing, i have the very same old, old, old computer, the "Trash 80" as it became to be called.
Mine is the portable version with the smaller CRT screen.
Yes, it boots in almost no time.
As to the operation, i used a "word processor" program (funny that's what it was called back then, when's the last time you heard that ha ha) that was written in less
than 32k Bytes (yes that is about 32000 bytes, not 32 megabytes, and not 320 megabytes). It was fast also.
I did a lot of asm programming on that as i had the need to do some modifications to the operating system when the date became greater than what the original OS could handle, and besides i enjoyed working with the Z80 microprocessor even before i got that computer.
The only sad part is the cost was about $1500 USD.

Yes, it would not work on the internet as it is today, no way. It may be able to do dial up with a modem though. I never got a modem for it nor even a mouse. I relied on the keyboard only, and the CRT screen and a dot matrix line printer for outputs.

Amazing that this did all that i really needed. I could probably still use a system like that today with no problem, except for the internet.
Funny, the CPU speed was just a mere 4MHz. That's easily 1000 times slower than the CPU's of today.