On Wednesday, October 11, 2023 at 10:42:08 AM UTC-4, S wrote:
> On Tuesday, August 29, 2023 at 5:09:56 AM UTC+10, Lorem Ipsum wrote:
> > On Monday, August 28, 2023 at 6:54:43 AM UTC-4, S wrote:
> > > On Wednesday, August 23, 2023 at 3:11:25 PM UTC+10, Lorem Ipsum wrote:
> > > > On Wednesday, August 23, 2023 at 12:15:40 AM UTC-4, S wrote:
> > > > > On Wednesday, August 23, 2023 at 5:22:50 AM UTC+10, Lorem Ipsum wrote:
> > > > > > On Tuesday, August 22, 2023 at 3:57:33 AM UTC-4, S wrote:
> > > > > > > On Tuesday, August 22, 2023 at 5:16:02 AM UTC+10, Lorem Ipsum wrote:
> > > > > > > > On Monday, August 21, 2023 at 3:02:58 PM UTC-4, S wrote:
> > > > > > > > > On Tuesday, August 22, 2023 at 3:41:50 AM UTC+10, Lorem Ipsum wrote:
> > > > > > > > > > On Monday, August 21, 2023 at 1:04:38 PM UTC-4, S wrote:
> > > > > > > > > > > On Sunday, July 23, 2023 at 3:10:24 PM UTC+10, yeti wrote:
> > > > > > > > > > > > Dave McGuire <mcg...@lssmuseum.org> writes:
> > > > > >
> > > ..
> > > > > Gass lighting again, and doing what you are accusing. You think you are so superior (Big) then you prove you can do it and have an idea?
> > > > I've never said I could fix the GA144. In fact, I'm pretty confident it is fully broken and can't be fixed.
> > > Merry go around again. You design these things for a living, you should be able to easily suggest changes to the conceptual architecture to "fix" it, of it had been broken, as it does what it was designed to do, or "improve" it more to our liking.
> > Your assumption is wrong. Personally, I think the design is fatally flawed and can not be "fixed". To be useful, multiprocessor designs require much more means of communications than simple neighbor connections can provide. I don't design multiprocessor designs, because I don't need billions of operations per second. If I do need very high performance processing, it would be for a specific application, and I would design custom processing for that in the FPGA.
> Good on you, but I've explained many times not doing what you are accusing me of, and have direct node addressing and simple multiple busses that answer your concerns. I'm hardly going to make things the same to change them.. But, I'm a lowly fool, what would I know.

What have I accused" you of exactly?

This is one of the reasons it's difficult to discuss anything with you. You talk in very abstract terms, so that I can't tell what you are reffering to.

The "assumption" I say is wrong, is the idea that every problem can be "fixed". There are fundamental limitations to any issue.

> > > ..
> > > > The Transputer CPUs are the only other ones I know of, that had anything like the GA144 communication connections. They were essentially serial connections, with a similar
> > > I had suggested they change that to a parallel connection. I thought they had announced talked about that.
> > Which has nothing to do with the issue of connectivity. The issue is not bandwidth, it's connections. Look up what a hypercube is. That is a structure that is useful for this. But, it still gets out of hand as the numbers of processors goes up. The real estate goes up ***HUGELY***. It's not workable. The GA144 isn't the first multiprocessor design ever attempted
> I did not realise, you don't design these systems.

I don't design what systems???

> Well, it's simple, you program down to the capabilities of the hardware. For my graphics processing unit, I couldn't resolve the design to be as useful as I wanted due to bandwidth constraints. Higher bandwidth would definitely solve everything, especially to external memory, with direct execute. Simple example. I could outline an elaborate structure to use the resources passing the data along and inserting data as it goes, but I was practically better off if I did most of it with just one processing node from external memory with execute The problem is, that raises production costs. But, the modifications go beyond that into treating groups of processors as sections that pass and receive data wherever it is needed. Careful embedded programming means you avoid choking the data path. As is, the chip suites low energy data passing and modification applications, as long as you don't try to get too ambitious and do something else, you should be fine. But, except for my graphics processor, sound, maybe something to do with storage and laser vector projection, that's not really me. I want what most of you do, flexible access and use, but that's not what this chip was aiming for, very low-end stream processing alternative to fpga's, at lower energy and cost. The feature set modifications to make it more useful generally, are very simple.I have often said, to have at least one processor as normal, able to use the array for extra processing and IO. My non blocking IO structure would make using the array for random access or neighbour, a cinch. Lots of objections solved. If you want to go up a few levels to a hypercube, go and buy one. I know that emulation of hypercube at low energy and reasonable speed (bandwidth plus the messaging improvements), is probably better. It ultimately is cheaper with lower energy and cost per unit of performance. Most applications do not require a full hypercube design, so there is a market underneath hypercube systems, as we regularly use. My previous old way of dividing up the work space, for my own design, is very different than normal. But, you can't get much improvement if you don't change things. The stuff I'm proposing for the GA, is just simple feature improvements using low hanging fruit.

Once you have a design description of this, let me know. I would be interested in funding an approach. But, it would require a clear, solid design approach.

> > > > handshake to the GA144. That also did not catch on very much.
> > > So, you don't support butted processor to processor parallel ports, and changing the hand shaking environment? That's what I proposed.
> > Let us know when you've run simulations, or built chips or at least done some calculations to show how well it would work.
> What, you mean those things any truely intelligent person can do in their heads? Pity Cray and Tesla aren't still around.

Yeah, it's funny, but the people who would use your designs would not understand anything you provide to explain the device.

> > > > I've read your posts, that's why I made the statement
> > > Sorry, accidentally deleted saying you should check my previous posts on it, where the truth is, and you acting like you missed it. Merry go around.
> > >
> > > I'm more likely to share the more than basic details with GA, than you.
> > Why are you talking to me at all? You virtually never like what I say. You claim I am a huge annoyance. Why bother?
>
> Why are you talking to me at all? You virtually never like what I say. You claim I am a huge annoyance. Why bother?
> Why follow me around in my threads?

I thought we have conversations, but you seem to think of my comments as rude or attacks. Why do you respond to me at all? Do you have a mental condition that you can't ignore my comments?

Besides, this is not YOUR thread. This was started by someone else. So, if you don't like my replies, too bad.

> > > > > > > That you don't have to try to use 700mips, and every cycle you use is more or less an minimal on actual work/communications, compared to everything both of us complain about in performance and programmability.
> > > ..
> > > > Ok, if you say so. What I actually said, was that you talk about speeding up the CPUs dramatically, as if that would somehow be a significant inprovement, while ignoring the fact that the current GA144 can't utilize but a small fraction of the CPU speed for most applications. Instead of responding to that, you go off into the deep woods.
> > > Where did I say that speeding up the processor was a general solution, you lost me in those woods? It might help with external memory access and acquisition, but not much of an improvement.
> > Sorry if I didn't understand what you were/are talking about. Speeding the processor(s) in the GA144 will add nothing to the memory interface. It may speed it up a bit, but then the demand for data will also be increased and you have gained nothing.
> Thanks for the apology Rick. It's a bit like Rick Chanchez? ...with me sometimes.
>
> The idea is to run more data and instructions from the external interface.. Fur my sequential data application, like a massive pipeline, speed helps. But, it's those general purpose processing modifications I need most. If only they had 512 words of sram per data node too, or 256MWord each, I could do Nintendo GBA/SNES like tricks with some 3D too.

The external interface will always be limited by the external interface. That's a major limitation in every high speed computing device, the memory interface, or the I/O interface. Internal processing can be increased by increasing the number of processors. But, the ultimate limitation is either internal comms or external comms, because they can not keep up with the number of processors.

> > > I did talk about redesigning the architecture as a major improvement in performance, then you can afd speed, which the redesign could handle, which is a seperate issue. Maybe you should just open source all your military designs,
> > LOL!!! I don't know what "afd speed" means. You can open source anything you want.
> You known what I meant.

No, I don't know what "afd speed" means.

> Open source, I was previously only aiming to open source certain things
> >
> > What "military" designs are you talking about? You seem to have gone off the deep end on this. When did I say anything about military designs?
> You told us you get military contracts. Why waste time?

I've never said I get military contracts. Please find a single post where I did say that.

> > > you like trying to get others to spill their IP, but what about giving your IP away for free, instead.
> > Why are you being a troll?
> Because I'm not, but you are often doing so. A troll acts stupid and makes mistakes, in order to bait a response.

No, a troll simply makes posts to get an inflammatory response. I'm trying to get straight answers out of you. That is very hard to do.

> But does not realise, unless he does it anonymously, he just ruins his own reputation. You think I think highly of people trolling Huge, for instance? Nope, they are fooling themselves. "What unethical conduct" and "Why ever hire somebody like that?", ethical employers might think.
>
> ...
> > > > > That this is a third generation of this type of device, after a few tested and proven generations at intelasys.
> > >
> > >
> > > > > Thank you Rick Collins. How are things at Artemis, you were working on a new FPGA Misc design? Why don't you start a thread and talk about that. Sounds very interesting, well it would be to me, I take interest in a number of different things, and people.
> > > > I don't do MISC designs for no reason. I am currently working on a new design for a customer, including an FPGA, but no MCU. It's actually a port of an existing design to replace
> > > > the obsolete FPGA and other chips. But, being property of a customer, I'm not at liberty to divulge the details.
> > > You mean, just like GA is not going to reveal details and of their business with customers
> > Nice talking to you.
> Thank you very much for that.

It's a shame I can't get logical comments from you as easily as you make inflammatory comments.

--

Rick C.

--+-+ Get 1,000 miles of free Supercharging
--+-+ Tesla referral code - https://ts.la/richard11209