Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.lang.forth > #23661

Re: On the importance of standards

Show all headers | View raw

On 6/13/2013 7:33 AM, Steve wrote:
> On Mon, 10 Jun 2013 11:35:33 -0400, rickman <gnuarm@gmail.com> wrote:
>> On 6/10/2013 6:13 AM, Steve wrote:
>> > On Sun, 09 Jun 2013 15:00:46 -0400, rickman <gnuarm@gmail.com>
> wrote:

> Always contrary, even to the correct answer you asked about. That was
> the subject, and for the final time that was the answer to what async
> was being used by whom.

I can't respond to this bizarre paragraph.


>> You miss my point. If you start to tailor the GPU for other apps,
> it is
>> no longer a GPU. You can retarget the device all you want and that
>> doesn't change what it was designed for.
>
>
> No, it is still a gpu, just a general purpose you that can do more than
> graphics, but as it still does gpu graphics it is still a gpu.
>
> You points don't make any objective sense Rick, as per before. They are
> just there to be contrary and generate traffic.
>
> You could say that a boat floats, but it could not be a boat because it
> carries passengers, antagonisingly insane. So a gpu remains a gpu, just
> like a boat remains a boat, don't matter how many dancing elephants
> might be on it. Fairy land again Rick.

Sure it does the GPU function still, but if it has been modified to do 
more than a GPU it is no longer just a GPU.  BTW, boats do carry 
passengers...

I'm not trying to argue with you.  I'm actually trying to get something 
out of you that makes sense and have some purpose.  If you want to 
argue, fine, you win all the rounds...


>> The volume of other markets is not so large, so I don't know Nvidia
> or
>> ATI have much reason to start customizing GPUs for any market other
> than
>> graphics. But you are always free to develop any app on them you
> wish.
...snip...
>> > Isn't that what I was saying just before you replied to, it
> doesn't make
>> > them not gpu's. Exciting times, a 32 bit high per misc would make
> it
>> > exciting in our corner too.
>
>
>> I know. Your comment about changing the GPU is off the mark
> because it
>> isn't going to happen until there is a market for the device.
>
>
> Another cake taker. Mr Collins has said that changing the gpu to do
> other things makes it not a GPU, then he directly goes onto say that
> they have changed them but they are still GPU's to contradict his
> previous statement in being contrary to what ever he is replying to. The
> fact that you'd are continually changing to do more, and also tap into
> seperate existing markets, is conveniently skipped.. He also illustrated
> how the ability of the technology tapped into another market, in
> contradiction to his next statement.

Ok, I acknowledge that GPUs have changed to take on wider roles than 
just graphics.  So what would you like to make of that?  I'm wrong, you 
are right.  Now what?


>> >> I don't know if this is done, but I would think the SIMD aspect
> of
>> > GPUs
>> >> would allow them to be used for weather calculations too. In
>> > essence
>> >> they are a poor man's Cray.
>> >
>> > Interesting thing is, that there are other high performance array
>> > options out there as alternative to misc that have been used for
> this,
>> > all processors clocked at low speeds to minimise power
> consumption, as
>> > misc does in reducing it's speed. The interesting thing is, it
> could be
>> > designed to be a lot faster even on it's present process. I would
> be
>> > interested to know if it could top 10ghz at 22nm Intel process.
> Linearly
>> > it should easily top tens of GHz, but in processes, life is not
> linear.
>
>
>> You've lost me on this one. Yes, there are any number of array
>> processors on a die. How does that relate to the GA144?
>
> Some how, from a point of interest about what he says being done by
> other processor array systems, he has got an objection with the "lost"
> angle, I have seen him use before that a senior member of this group has
> been victim of, following up his posts to help him. In relating what
> could be done on misc if sped up, if possible, he conveniently skips and
> shoves a off topic processor in place of a enhanced future misc design.
> Is the ga144 at all on topic here in this conversation, as we are only
> really exclusively talking enhanced misc designs, preferably at 32 bits.
> The only thing we discussed is it's relative size before a external
> execution ready memory bus was added, wasn't it. Confusing Rick.

I have no idea what you are saying...  Your writing is very hard to 
follow and your ideas ramble on.  Constantly complaining about my 
replies doesn't help at all.  Can you focus and try to explain your 
thoughts in just a few words?

I think you want to talk about 32 bit MISC processors.  I guess you were 
speculating that they can run much faster than 700 MHz.  Ok, I'm sure 
that is true.  What about it?


>> I can't say how fast it might run on a 22 nm process. But it will
> also
>> use a *lot* more power. With the smaller feature sizes the static
> power
>> goes up dramatically. Somewhere around 45/65 nm or so it began to
>> dominate the power consumption of many chips. The FinFET and other
> 3D
>> structures help, but for true low power you need to stay with 120
> nm and
>> above depending on your needs. My friend's iPhone won't run the
> full
>> day without a charge. Not overly useful in my opinion. That is
> sub 45
>> nm design.
>
> I think I covered this previously in why Nvidia is using the async like
> block processing.

Perhaps you don't understand static power consumption.  Or maybe I don't 
understand what you are saying about power consumption.  I certainly 
don't know what "async like block processing" is.  Can you point to a 
reference that explains this?

Static power is the power used by a chip the entire time it is powered 
up, regardless of the clocking.  You can stop all clocks, stop all 
processing and the chip still draws power.  At the feature sizes used on 
the GA144 the static power consumption is very low.  This is *not* a 
design feature of the logic of the device.  This is inherent in the 
process technology and mostly determined by the feature size.  As the 
feature size shrinks the oxides get thinner requiring lower voltages to 
be used.  Somewhere in the 1.2-1.5 volt range there is no longer enough 
voltage to fully switch the transistors and they are not entirely turned 
off.  So the static power consumption goes up.

I think the static current levels peaked a generation or two ago in the 
large CPUs and possibly FPGAs.  The problem had become so large that the 
static power consumption was nearly as large as the dynamic consumption 
in the big iron CPUs.  The market was moving to battery operation, so 
they started to deal with it.  The most recent "innovation" is the "3d 
FinFET" by Intel and similar designs by many others.  In these 
transistors the gate wraps around three sides of the channel creating a 
much stronger field in the channel.  This allows the channel to be fully 
turned on and off from the current Vdd levels which I believe are below 
1 volt.  But this is no panacea.

The GA144 chip has a static current consumption of ~13 uW.  The power 
consumption when all cores are fully utilized is almost 1 Watt.  I'm not 
sure how the dynamic power consumption would change going to a 22 nm 
process, but the static power would rise to some level well above 1 mW. 
  That is a key feature of the GA144 for battery powered apps.  If you 
lose the very low static power consumption it won't be useful for 
battery powered apps anymore, or at least it won't be any better than 
other devices.


>> Talk to GA. For some apps that would be true. If you consider the
> FPGA
>> model it might make sense to have some blocks of RAM scattered
> around.
>> Say one in 16 nodes could be replaced by a block of RAM attached to
> one
>> CPU. That would be minimal routing, but it would disrupt the
> regularity
>> of the structure. In FPGAs they tend to use a full column or a
> full row
>> for special features like this.
>
> Look Mr Collins, all I'm saying is that I would like to see misc
> improved with simple features to be more useful to all in the MCU/CPU
> arena, even gpu, rather than being the pure fpga alternative, as you
> have suggested. All that is up for grabs if you are willing to pay for
> it, potentially I am, when I have the money spare, and if it is still
> the right choice etc.

You are free to spend your money as you choose.  But the fact that you 
spend money does not mean MISC will solve all problems.  That is where 
we have differences.

Yes, I would love to see the GA144 changed or another chip designed as a 
proper MCU.  I don't have the cash to do that and GA doesn't seem to 
agree with my ideas of what is needed.


> On ram modules, you could have one module between 4 or 8 cores, use 1
> transistor Ram technology for greater memory density, maintained to look
> like SRAM to the node.

Yes, you could do that.  But it is easy to say, do this, do that.  It is 
important to have some understanding of what apps would benefit from 
features and which features are optimal and which are not.


>> I don't work for GA so I doubt they are interested in my ideas.
>
> He, he, but they still listen to good ideas I think, maybe not as often.
> Thanks you for turning up again Mr Collins.

I think they have their own idea of what is "good".  Everyone does.


> Talking
>> > about it just gets me sick of waiting.
>
>
>> What makes sense to us is not the same as what makes sense to GA.
> They
>> have the bums in the seats and the hats on the heads or whatever
>> expression you want to use for feeling the impact of the decisions.
>
> Now I don't get it?

GA is the entity that wins or loses based on the decisions they make 
regarding the chips they produce.  We can speculate all we want.  But 
they are a tiny company on the edge of existence and have to make their 
own decisions.


> It is just the objective reality, good business through the door keeps
> things going. In the end, that is what keeps many companies going.

Yes.


>> I don't think you understand why the F18 memory is limited to 64
> words
>> of RAM. First, there is the space RAM takes up. It is already a
> large
>> part of each F18. Second there is the power it uses. But most
>> importantly, it is because the designer, Chuck Moore feels this is
> all
>> that is needed in an F18. GA seems to agree with him just as they
> don't
>> feel the need to support on chip useful interfaces like high speed
> USB
>> or 100 Mbps Ethernet.
>
> I do, we have covered this already, it is there to reread. A redesign
> was mentioned, applied to one or a few nodes, to have an external memory
> bus and addressing, all nodes if desired. So yes, with one node having
> an external memory bus 64 words can still be sufficient for all the
> others, each. Mr Moore's vision is unbroken in that way. And as far as
> 'power' requirements goes, if you need it, it is not a disadvantage, and
> definitely more economical that trying to get multiple cores to do an
> soft bus at a reaction of the performance, and if you don't need it then
> the pins are used as io, and that single node may have very little extra
> power usage.

I'm all *for* an proper external memory interface on the GA144.  They 
already have the pins on the chip for communicating with 1.8 volt 
memories of which there are plenty to choose from.  They have decided to 
support async memory which is higher power and lower capacity than DRAM. 
  They also only provide an interface in software which is slow.  There 
is no good reason to not provide a *proper* memory interface supporting 
multiple memory types.

-- 

Rick

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: On the importance of standards Joshua Litt <jalitt@gmail.com> - 2013-06-06 17:15 -0700
  Re: On the importance of standards "Elizabeth D. Rather" <erather@forth.com> - 2013-06-06 14:45 -1000
    Re: On the importance of standards Joshua Litt <jalitt@gmail.com> - 2013-06-06 19:24 -0700
      Re: On the importance of standards Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-06-06 21:38 -0500
        Re: On the importance of standards Joshua Litt <jalitt@gmail.com> - 2013-06-07 14:39 -0700
          Re: On the importance of standards Steve <nospam275@gmail.com> - 2013-06-09 00:57 +1000
            Re: On the importance of standards Paul Rubin <no.email@nospam.invalid> - 2013-06-08 10:44 -0700
              Re: On the importance of standards Steve <nospam275@gmail.com> - 2013-06-09 06:11 +1000
                Re: On the importance of standards Paul Rubin <no.email@nospam.invalid> - 2013-06-08 14:47 -0700
                Re: On the importance of standards Steve <nospam275@gmail.com> - 2013-06-10 00:03 +1000
                Re: On the importance of standards rickman <gnuarm@gmail.com> - 2013-06-09 15:00 -0400
                Re: On the importance of standards Paul Rubin <no.email@nospam.invalid> - 2013-06-09 12:26 -0700
                Re: On the importance of standards rickman <gnuarm@gmail.com> - 2013-06-09 15:41 -0400
                Re: On the importance of standards Paul Rubin <no.email@nospam.invalid> - 2013-06-09 13:11 -0700
                Re: On the importance of standards Paul Rubin <no.email@nospam.invalid> - 2013-06-09 13:14 -0700
                Re: On the importance of standards Steve <nospam275@gmail.com> - 2013-06-10 18:41 +1000
                Re: On the importance of standards rickman <gnuarm@gmail.com> - 2013-06-09 17:09 -0400
                Re: On the importance of standards Steve <nospam275@gmail.com> - 2013-06-10 18:35 +1000
                Re: On the importance of standards Bernd Paysan <bernd.paysan@gmx.de> - 2013-06-10 16:04 +0200
                Re: On the importance of standards Paul Rubin <no.email@nospam.invalid> - 2013-06-15 01:08 -0700
                Re: On the importance of standards Steve <nospam275@gmail.com> - 2013-06-10 20:13 +1000
                Re: On the importance of standards rickman <gnuarm@gmail.com> - 2013-06-10 11:35 -0400
                Re: On the importance of standards Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-06-10 17:37 -0500
                Re: On the importance of standards rickman <gnuarm@gmail.com> - 2013-06-10 18:46 -0400
                Re: On the importance of standards Paul Rubin <no.email@nospam.invalid> - 2013-06-10 16:36 -0700
                Re: On the importance of standards rickman <gnuarm@gmail.com> - 2013-06-10 20:09 -0400
                Re: On the importance of standards Steve <nospam275@gmail.com> - 2013-06-13 21:55 +1000
                Re: On the importance of standards Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-06-11 09:56 -0500
                Re: On the importance of standards Bernd Paysan <bernd.paysan@gmx.de> - 2013-06-11 18:40 +0200
                Re: On the importance of standards rickman <gnuarm@gmail.com> - 2013-06-11 22:36 -0400
                Re: On the importance of standards Bernd Paysan <bernd.paysan@gmx.de> - 2013-06-15 14:30 +0200
                Re: On the importance of standards rickman <gnuarm@gmail.com> - 2013-06-15 19:20 -0400
                Re: On the importance of standards Bernd Paysan <bernd.paysan@gmx.de> - 2013-06-16 22:37 +0200
                Re: On the importance of standards Steve <nospam275@gmail.com> - 2013-06-23 17:14 +1000
                Re: On the importance of standards Steve <nospam275@gmail.com> - 2013-06-13 21:33 +1000
                Re: On the importance of standards rickman <gnuarm@gmail.com> - 2013-06-15 13:21 -0400
                Re: On the importance of standards Steve <nospam275@gmail.com> - 2013-06-23 18:58 +1000
                Re: On the importance of standards rickman <gnuarm@gmail.com> - 2013-06-08 18:42 -0400
                Re: On the importance of standards Steve <nospam275@gmail.com> - 2013-06-09 23:27 +1000
              Re: On the importance of standards "WJ" <w_a_x_man@yahoo.com> - 2013-06-10 16:11 +0000
  Re: On the importance of standards Steve <nospam275@gmail.com> - 2013-06-08 05:11 +1000

csiph-web