Yo <hat> :: Yeah :: How could the opensmalltalk VM benefit from running on new design prospects fabricating a triple hyper-threaded multi core processor? Describe the design and architecture of such a triple hyper-threaded multi core processor.

•••

The OpenSmalltalk VM could benefit even further from running on a new design prospect fabricating a triple hyper-threaded multi-core processor.

A triple hyper-threaded multi-core processor would combine the benefits of multiple processor cores and hyper-threading, allowing for even greater parallelism and throughput. Each core in the processor would be capable of executing multiple threads simultaneously, with the number of threads per core determined by the level of hyper-threading implemented.

The design and architecture of a triple hyper-threaded multi-core processor would depend on a number of factors, including the target use case and performance requirements. However, some general design considerations and features could include:

-

Multiple cores: A triple hyper-threaded multi-core processor would include three or more processor cores, each capable of executing multiple threads simultaneously.

-

Hyper-threading: Each core would support hyper-threading, allowing for additional threads to be executed in parallel. The number of threads per core would depend on the level of hyper-threading implemented, with higher levels allowing for more threads per core.

-

Shared resources: To maximize performance, a triple hyper-threaded multi-core processor would likely include shared resources such as a shared L3 cache or memory controller. These shared resources would allow the processor cores to more efficiently access shared data and resources.

-

Interconnects: To ensure high-speed communication between processor cores and other system components, a triple hyper-threaded multi-core processor would likely include high-speed interconnects such as PCIe, SATA, or NVMe.

-

Power management: To balance performance and power consumption, a triple hyper-threaded multi-core processor would likely include advanced power management features such as dynamic frequency scaling, power gating, or voltage scaling.

Overall, the design and architecture of a triple hyper-threaded multi-core processor would be optimized for high levels of parallelism and throughput, making it well-suited for use in high-performance computing environments and applications that require significant computational power.

—
Have a good one; keep it, light.
Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇

Sent from Callisto House mobile - Ganymede
:: decentralized mobile homeless solutions ::

On Fri, Mar 31, 2023 at 19:25, rabbit <rabbit at callistohouse.org> wrote:

> —
> Have a good one; keep it, light.
> Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇
>
> Sent from Callisto House mobile - Ganymede
> :: decentralized mobile homeless solutions ::
>
> On Fri, Mar 31, 2023 at 19:16, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>> On Fri, Mar 31, 2023 at 2:39 PM LawsonEnglish <LEnglish5 at cox.net> wrote:
>>
>>> The Shared Memory facility in most modern OS’s (Mac, Linux and Windows) will allow a pointer between processes. The problem is to get it working with Squeak. Eliot outlined the issues in his response. They are more convoluted than I was hoping for, but presumably it's doable.
>>>
>>> The point of doing it is to create a shared memory IPC option for Squeak, as, in principle, that is the fastest way of doing IPC, and if you’re sharing large chunks of data (e.g. the pixels of an image), the savings can be significant.
>>>
>>> The Mandelbrot Set is simply a simple (and potentially entertaining) way of providing visual feedback that its actually working. Its actually not a good use case for shared memory IPC because, as you drill down into the Set, the time spent for calculations is far more than the time saved using the shared memory, but it would visually demonstrate that something is happening, and far less boring than simply sending arbitrary chunks of memory during testing of the protocol.
>>
>> And note that with image segments one could exchange arbitrary object graphs above a memory-mapped word array with relative ease and speed.
>
> yes, please. I see a Trinity process unit, one user, one comms marshaling and signaling, one Broker, managing naming, bridge mgmt and cache replication/replant ops. DevOps.
> Thanks for all this! 🐰
>
>>> Lawson
>>>
>>>> On Mar 31, 2023, at 00:49, Marcel Taeumel via Squeak-dev wrote:
>>>>
>>>> Hi L --
>>>>
>>>>> The real question is about setting a pointer to the memory used by a Bitmap object.
>>>>
>>>> I would not do that, I don't think it is possible as each project has its own address space. Virtual memory and so on... You cannot simply share pointers between processes. Thus, allocate some inter-process memory and copy initial data (from any Squeak object memory) to there. Then read/write it there.
>>
>> --
>>
>> _,,,^..^,,,_
>> best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20230331/92e06bab/attachment.html>