From Newsgroup: sci.physics.relativity

Mild Shock wrote:

Hi,

Assume that we live in a world where we have excess memory. So we can
afford stacks! And then make the crucial observation,

we can use the stack of the Prolog engine,
no need to create an artificial stack in C,
or use the native stack of C.

I guess SWI-Prolog has already groked the first we can "afford stacks".
But did anybody already grok the "100% Prolog" idea?

Well we are not yet there 100% Prolog has still an overhead. Here is a
little test acyclic_term/2:

/* SWI-Prolog 9.3.26, C Stacks and/or Agendas */ ?-
time((between(1,30,_), acyclic2, fail; true)).
% 330,150 inferences, 0.016 CPU in 0.023 seconds (69% CPU, 21129600
Lips) true.

you assume too much. The 'overheat' is merely based on the size of memory required, and the number of instructions sent to the CPU's decoder,
together with data, occupying the bus, through the pipeline, ignoring the pipeline etc. Not directly related to time. And 'stacks' ARE memory, not something to 'afford as excess' fucking stoopid.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.physics.relativity



I guess your brain was "overheating".

LoL

The problem of L1, L2, L3, cache trashing through
writes, is not overheating, but it gets awfully slow,
creating an overhead not overheating.

Cache trashing (or cache thrashing) in the context
of L1, L2, and L3 CPU caches is a performance issue,
not a thermal one.

Jordon Molokovsky schrieb:

Mild Shock wrote:

Hi,

Assume that we live in a world where we have excess memory. So we can
afford stacks! And then make the crucial observation,

we can use the stack of the Prolog engine,
no need to create an artificial stack in C,
or use the native stack of C.

I guess SWI-Prolog has already groked the first we can "afford stacks".
But did anybody already grok the "100% Prolog" idea?

Well we are not yet there 100% Prolog has still an overhead. Here is a
little test acyclic_term/2:

/* SWI-Prolog 9.3.26, C Stacks and/or Agendas */ ?-
time((between(1,30,_), acyclic2, fail; true)).
% 330,150 inferences, 0.016 CPU in 0.023 seconds (69% CPU, 21129600
Lips) true.

you assume too much. The 'overheat' is merely based on the size of memory required, and the number of instructions sent to the CPU's decoder,
together with data, occupying the bus, through the pipeline, ignoring the pipeline etc. Not directly related to time. And 'stacks' ARE memory, not something to 'afford as excess' fucking stoopid.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.physics.relativity

Mild Shock wrote:

I guess your brain was "overheating".

LoL

The problem of L1, L2, L3, cache trashing through writes, is not overheating, but it gets awfully slow,
creating an overhead not overheating.

yet the uneducated visiting professor imbecile, undrestanding nothing all areas in everything. Nobody said 'overheating', cant you read the
punctuation, you lying piece of shit
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.physics.relativity

Mild Shock wrote:

The problem of L1, L2, L3, cache trashing through writes, is not overheating, but it gets awfully slow,
creating an overhead not overheating.

so fooling around needlessly in CPU's cache is not increasing the
temperature.. ; get yourself a proper education, before opening your
stupid mouth.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.physics.relativity


overheat:
https://en.wikipedia.org/wiki/Overheating_(electricity)

overhead:
https://en.wikipedia.org/wiki/Overhead_(computing)

Emile Paduchev schrieb:

Mild Shock wrote:

I guess your brain was "overheating".

LoL

The problem of L1, L2, L3, cache trashing through writes, is not
overheating, but it gets awfully slow,
creating an overhead not overheating.

yet the uneducated visiting professor imbecile, undrestanding nothing all areas in everything. Nobody said 'overheating', cant you read the punctuation, you lying piece of shit

--- Synchronet 3.21a-Linux NewsLink 1.2