"Wolfgang Kern" <nowhere@[EMAIL PROTECTED]
> wrote in message
news:g5v39m$5jq$1@[EMAIL PROTECTED]
>
> "cr88192" wrote:
> ...
>> in part, I was referencing some typical sci-fi cliches in movies and
> games, > where very often some piece of machinery exists doing some
> fantastical task,
>> which are usually presented in a certain way:
>> large spining objects, such as rotors, or those multiple-interconnected
>> spinning rings (yes, I have seen them do everything from interstellar
>> trans****tation to digitizing someone and sending them onto the internet
> with
>> these);
>> some kind of loud noise, with metalic screeching being most common,
maybe
>> followed by low-pitched rumbling;
>> usually there is some kind of bright lightsource in the middle (most
>> often
>> with a blue or green tint);
>
> When I was about ten, I played with this huge light-bulb styled diodes,
> which produced an astoni****ng blue light cloud if they were overpowered.
> And I often find exactly this effect in early and latest sci-fi movies.
>
maybe that is it...
I had thought it would have been some sort of flourescent, but maybe this
could be it as well...
>> in general, these have replaced the lightning, jacob's ladders, and
>> vacuum
>> tubes that were more common in older movies. the more modern
replacement
>> (typically for far less powerful side devices) being tesla coils, those
>> 'lightning in a piece of plastic' things, and tubes filled with glowing
>> liquid.
>
>> in a lot of newer stuff, what would seem to be flourescent bulbs in
some
>> kind of fancy housing, are also gaining in popularity (an example of
this
>> would be the smaller 'arc-reactor' in the iron-man movie...).
>> albeit I have seen this approach also used a lot in star-trek and
> friends...
>>
>> then I ended up making a few minor new-age and web-culture references.
>>
>> for example:
>>
>
http://www.youtube.com/results?search_query=shoop+da+whoop&search_type=&aq=f
>
> Oh, they actually made a cult out of it...
>
that and many other things, desu...
http://www.youtube.com/results?search_query=4chan&search_type=
http://www.youtube.com/results?search_query=desu&search_type=&aq=f
....
>> but, yes, the unrelenting nature and incoherent nature of the posts,
and
>> their occurance on a number of different newsgroups (related to
seemingly
>> arbitrary topics), make me uncertain as to whether the OP is an actual
>> person, or just some kind of chatbot (actually, I have seen a lot more
>> coherent and human-like responses made by chatbots in the past, making
me
>> wonder if this would even be a very good one...).
>
> Who knows, not too long ago I saw a suggestion to use A.L.A as a
> test-group for social behaviour. Perhaps they now test our response to
> 'Artificial Nonsense' like 'Flying Bucket' posts and similar.
>
yes, maybe...
sadly, I don't have much on-topic to say, not having done a whole lot ASM
or
compiler related recently.
of well, I have recently noted that both AMD and Intel have their own
ideas
for how to extend C and C++ to handle large array-like vectors.
I am left with another idea:
how about we make a "conservative" set of extensions for this kind of
thing:
_Vector float a[100], b[100], c[100];
c=a*a+b;
now, how to pull this off is left to the compiler...
this is beyond my personal extensions, which just consist of a few
elements
from GLSL onto C's syntax.
it being my idea that we can add constructs that people already use, such
as
vector geometry, quaternions, and matrices (of which I have done largely
absent adding any novel syntax).
vector-arrays could go into this set, but this is just how I imagine them:
as vector arrays.
as I see it, we could just change the semantics so that they are
pass-by-value, and add in code such that operations can be parallelized
(leaving many of the optimization details still in the hands of the
compiler).
(or, alternatively, people could just extend GCC's pre-existing albeit
horrid vector syntax to handle much larger vectors, and add more
bulk-parallelization sup****t to GCC...).
now, here is what AMD proposes:
kernel void sum(float a<>, float b<>, out float c<>)
{
c = a + b;
}
int main(int argc, char** argv)
{
int i, j;
float a<10, 10>;
float b<10, 10>;
float c<10, 10>;
float input_a[10][10];
float input_b[10][10];
float input_c[10][10];
for(i=0; i<10; i++) {
for(j=0; j<10; j++) {
input_a[i][j] = (float) i;
input_b[i][j] = (float) j;
}
}
streamRead(a, input_a);
streamRead(b, input_b);
sum(a, b, c);
streamWrite(c, input_c);
...
}
and, personally, I don't see why...
(Intel's option is similar, but is C++ based).
so, as I could imagine the above:
_Vector float[] sum(_Vector float a[], _Vector float b[])
{
c = a + b;
}
int main(int argc, char** argv)
{
int i, j;
_Vector float a[10][10];
_Vector float b[10][10];
_Vector float c[10][10];
for(i=0; i<10; i++) {
for(j=0; j<10; j++) {
a[i][j] = (float) i;
b[i][j] = (float) j;
}
}
c=sum(a, b);
...
}
now, _Vector is a little ugly (but could be largely macro'ed away).
now, it would be expected than when directly manipulating these vectors,
they would be "serialized", and serious limitations would be put on the
use
of pointers (probably creating something semantically equivalent, but
processed linearly).
to make it really spiffy, it could sup****t certain kinds of tensor
operations:
for(i=0; i<10; i++)
for(j=0; j<10; j++)
c[i][j]=a[i][]^b[][j];
where A^B is a dot-product (me finding that A*B being a pairwise multiply
is
more useful than it would seem, and so A^B is probably better for
dot-product, leaving A*B for the pairwise-multiply operation).
note that it will be expected that the compiler will notice that it can
parallelize these for's as well, but this is just assuming it is not
enough
just to parallelize the vectror and tensor operations.
granted that, in any case, vectorization and parallelization, or for that
matter offloading things to the GPU, is likely to involve more than a
little
voodoo magic in the compiler.
note that, in the above, the 'for' statements are likely to be
pattern-matched and regarded simply as a statement of the range of values
within the expression, rather than them actually being interpreted as for
statements (basically, it is conceptually similar to loop unrolling and
similar).
or such...
> __
> wolfgang
>
|
