Discovery: Concurrency problems might be used to create ps..

On Dec 1, 9:35 pm, "Skybuck Flying" <s....DeleteThis@hotmail.com> wrote:
> Hello,
>
> Kinda interesting idea:
>
> Just create multiple threads/instances let them execute some instructions...
>
> The concurrency/race conditions could lead to possibly usuable filling
> patterns for corewars, or maybe even pseudo random number generators for
> general applications.
>
> Added benefit very simply instructions already lead to interesting
> patterns...
>
> Bye,
> Skybuck.

If the threads execute repetitive instructions, the concurrency
patterns will be highly regular.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

How so ?

Different instructions have different latencies.

Multiple threads executing all kinds of weird maybe even useless
instructions might end-up getting slightly different ammounts of time slices
etc...

This could create difficult to predict random numbers ?

In other words, given enough instructions threads will not execute perfectly
in sync, but different...

Bye,
Skybuck.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

Skybuck Flying wrote:
> How so ?
>
> Different instructions have different latencies.
>
> Multiple threads executing all kinds of weird maybe even useless
> instructions might end-up getting slightly different ammounts of time slices
> etc...
>
> This could create difficult to predict random numbers ?
>
> In other words, given enough instructions threads will not execute perfectly
> in sync, but different...
>
> Bye,
> Skybuck.
>
>
>
Skybuck again you have no idea what you are talking about

they tend to fall into a pattern - - - so as to not create a totally
random sequence of numbers - - - -

the best way is to use the microsecond counter in the hardware and read
this upon each keystroke entered - - - at least for DOS this works - -
and use this as the seed for the random number generator

as for the different instructions have different latencies - -
but it is still the same set of code running - - - so each time the code
takes the same amount of time - - -

as for different types of weird and useless instructions - - same code
each loop so same time effects and same pattern of execution will occur.

again your lack of computer knowledge is showing

Jim P.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

No your lack of knowledge is showing.

Try writing some multi threaded program and then try to keep the threads in
sync !

Show me a demonstration too

I once wrote some gui with threads and such and the stuff started running
out of sync while it was the same code as far as I can remember !

Bye,
Skybuck.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

Skybuck Flying wrote:
> No your lack of knowledge is showing.
>
> Try writing some multi threaded program and then try to keep the threads in
> sync !
>
> Show me a demonstration too
>
> I once wrote some gui with threads and such and the stuff started running
> out of sync while it was the same code as far as I can remember !
>
> Bye,
> Skybuck.
>
>
the lack of understanding aways shows

the fact that you will argue and argue to prove that you might be right
is always skybuck - - -

why prove what to most is simple logic - - -

and in your code you had lots of bugs - - and were not testing to
see how the code was interacting - - - -

Jim P.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

Time slices are based on time.

CPU's don't work with time.

They work with clock ticks.

I cpu doesn't care at what frequency it's running.

There it's only logically threads don't run at the same speed.

Add amd's cool & quiet and it becomes probably even more spectacular swings.

Bye,
Skybuck.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

On Fri, 21 Dec 2007 08:55:29 +0100, "Skybuck Flying"
<spam RemoveThis @hotmail.com> wrote:

>Time slices are based on time.
>
>CPU's don't work with time.
>
>They work with clock ticks.
>
>I cpu doesn't care at what frequency it's running.
>
>There it's only logically threads don't run at the same speed.
>
>Add amd's cool & quiet and it becomes probably even more spectacular swings.

Come on then..prove all this with some code. We're all dying to see
it..

--
Z
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

I have no time to experiment with this idea.

Nor am I really interested in it at this point in time.

Finally one needs to find some nice instructions which play well together
and maybe have a good distribution or so and still unpredictable

Bye,
Skybuck.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

And ofcourse this mostly applies to real cpu's not simulated cpu's like
corewars.

However even in corewars it could create nice fake random number generators
with nice fillings.

Much easier instructions than a common number generator.

Bye,
Skybuck.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

Skybuck Flying wrote:
> Time slices are based on time.
>
> CPU's don't work with time.
>
> They work with clock ticks.
>
> I cpu doesn't care at what frequency it's running.
>
> There it's only logically threads don't run at the same speed.
>
> Add amd's cool & quiet and it becomes probably even more spectacular swings.
>
> Bye,
> Skybuck.
>
>
like I said - - - total lack of understanding - - -
this is independent of clock speed - - this is independent of clock ticks

and the threads will tend to sync - - that is part of how the OS works
and the effect that can be expected - - -

And what does AMD's processor have to do with this - over Intel
Nothing at all - - - - -

again you are going to beat a dead horse till you stink just like you do
all the time - - - ugh is my comment to you

Jim P.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

Skybuck Flying wrote:
> I have no time to experiment with this idea.
>
> Nor am I really interested in it at this point in time.
>
> Finally one needs to find some nice instructions which play well together
> and maybe have a good distribution or so and still unpredictable
>
> Bye,
> Skybuck.
>
>
>
Ah - - our point - - a Skybuck Idea that has never been tested and never
will be tested - - - just argue to prove a point but will not take the
time to see if your idea has any merit at all - - - while the whole time
saying that it does - - - against quite a few people that know that it
will not - - - -

and it does not matter what instructions - - the code runs the
instructions as it should - - this number of clock cycles for this one
and this number for that one - - - does not matter what the instructions
are - - - -

Code is designed to be predictable - - not random

Jim P.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

The problem is the solution.

But you don't get it

Bye,
Skybuck.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

On Fri, 21 Dec 2007 12:05:41 +0100, "Skybuck Flying"
<spam.DeleteThis@hotmail.com> wrote:

>I have no time to experiment with this idea.

Ha Ha..you mean you are not *able* to code it!

>Nor am I really interested in it at this point in time.

Quote from your original post:

>Kinda interesting idea:

No it isn't..you've now said you're not interested!

>Added benefit very simply instructions already lead to interesting
>patterns...

No, not very interesting at all.

>Finally one needs to find some nice instructions

Shame you can't do that..I was *really* looking forward to some
SkyBuck multi-threaded code..honestly!

--
Z
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps..