Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #48572

Re: Kilocore

Show all headers | View raw

rickman <gnuarm@gmail.com> writes:
>On 6/26/2016 5:58 AM, Anton Ertl wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> On 6/25/2016 10:10 AM, Anton Ertl wrote:
>>>> rickman <gnuarm@gmail.com> writes:
>>>>> On 6/24/2016 11:57 AM, Anton Ertl wrote:
>>>>>> rickman <gnuarm@gmail.com> writes:
>>>>>>> On 6/24/2016 6:21 AM, Anton Ertl wrote:
>>>>>>>> rickman <gnuarm@gmail.com> writes:
>>>>>>>>> I don't want to offend, but I think the idea that someone would spend
>>>>>>>>> half a mil building a chip without any idea of how to program it is a
>>>>>>>>> bit of nonsense.
>>>>>>>>
>>>>>>>> Sure they have an idea how to program it.  Sometimes these ideas scale
>>>>>>>> to development of bigger software, and sometimes they don't.  Now will
>>>>>>>> you spend a few millions on software development for a hardware model
>>>>>>>> before you know that you can actually build the hardware?
>>>>>>>
>>>>>>> Where is the risk in building hardware at a process node more than five
>>>>>>> years old?
>>>>>>
>>>>>> Hardware with design parameters that no one has tried before?  Risks:
>>>>>> Do you get it to work?  Do you get it to perform?
>>>>>
>>>>> Design parameters such as what?
>>>>
>>>> Number of cores in the example of KiloCore.  Will the interconnect
>>>> scale for real software loads with inter-core communications?
>>>
>>> That is not a risk in building the hardware.  That is a risk in
>>> configuration and perhaps even basic design which would all be modeled
>>> in software before even starting the detailed chip design.
>>
>> Sure, but what you can do in simulation is limited, and simulation is
>> not free, either.  At some point you have gone as far as practical
>> with simulation, and then you build it, and it can still turn out that
>> the interconnect is not up to the demands of real software for this
>> chip.
>
>None of that is relevant to the original statement above.  What is your 
>point?  Besides, simulation capabilities are pretty f'ing huge these 
>days.  There is not much that can't be calculated or simulated.

A cycle-accurate simulation of a 1000-core design will be several
orders of magnitude slower than the hardware even if you have 1000
cores in the simulator; especially simulating the interconnect is
likely to be slow.  And you can only simulate running software that
you have, so if you want to simulate more than just a few benchmarks,
you will have to do some serious software development.

My point is: "At some point you have gone as far as practical
with simulation, and then you build it, and it can still turn out that
the interconnect is not up to the demands of real software for this
chip."  And I think this is relevant to the discussion at hand.

>>>>> The issue of performance is much more
>>>>> of a risk in the software than the hardware.
>>>>
>>>> Nobody cares for a word processor that's ten times faster than MS
>>>> Word.  OTOH, if your hardware is half as fast as the competition, you
>>>> are toast.  Actually, looking at how AMD has fared lately, much less
>>>> than a factor of 2 is already a big problem.
>>>
>>> I have no idea what your point is.
>>
>> I gave an example that contradicts your claim.
>
>I have no idea what you are talking about.

"The issue of performance is much more of a risk in the software than
the hardware."

People often care more about other things in software, so bad
performance is not such a big problem, and performance is not such a
big risk (although that leads to the kind of don't-care-for-performace
programming that leads to problems that are big enough to make
projects fail; risk homeostatis at work).

>> Why should a software maker invest in verifying a hardware design,
>> especially one based on untried principles?
>
>Again you have drifted far off the original topic, a hardware design 
>that should be evaluated in the context of the software that would run 
>on it before being built.

That's your claim, and you tried to support it with claims about
software makers funding hardware development; I followed you there,
and now you complain about me drifting from the original topic.
Funny.

>> Sure, they write some benchmarks to show off the capabilities of their
>> chips, but they certainly won't be doing any multi-year software
>> development effort for it.  Maybe the hardware department will
>> cooperate with a software department which will explore software
>> scalability to some areas opened up by that chip, but the result will
>> also just be proof-of-concepts.
>
>If they don't write software for it, who will?

Who knows.  They have their paper published (or probably several).
Mission accomplished.  Maybe there will be papers about programming
the thing, maybe not.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

Thread

Kilocore Brad Eckert <hwfwguy@gmail.com> - 2016-06-22 21:56 -0700
  Re: Kilocore Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-23 03:09 -0500
  Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-23 09:59 -0400
    Re: Kilocore anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-23 14:31 +0000
      Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-23 16:22 -0400
        Re: Kilocore anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-24 10:21 +0000
          Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-24 11:37 -0400
            Re: Kilocore anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-24 15:57 +0000
              Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-24 12:26 -0400
                Re: Kilocore anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-25 14:10 +0000
                Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-25 14:00 -0400
                Re: Kilocore anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-26 09:58 +0000
                Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-26 15:17 -0400
                Re: Kilocore anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-27 14:40 +0000
                Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-27 12:39 -0400
                Re: Kilocore Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-27 14:50 -0500
                Re: Kilocore Paul Rubin <no.email@nospam.invalid> - 2016-06-27 12:59 -0700
                Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-27 16:05 -0400
                Re: Kilocore Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-27 15:17 -0500
                Re: Kilocore hughaguilar96@gmail.com - 2016-06-26 15:46 -0700
  Re: Kilocore anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-23 14:15 +0000
    Re: Kilocore Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-23 11:57 -0500
    Re: Kilocore rickman <gnuarm@gmail.com> - 2016-06-23 16:25 -0400
  Re: Kilocore Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-06-24 04:18 -0700
    Re: Kilocore Brad Eckert <hwfwguy@gmail.com> - 2016-06-24 21:48 -0700
  Re: Kilocore endlessboomcapitalism@gmail.com - 2016-06-23 22:32 -0700
  Re: Kilocore darek.maksimiuk@gmail.com - 2016-06-26 13:12 -0700
  Re: Kilocore Mat <dambere@web.de> - 2016-06-26 16:36 -0700
  Re: Kilocore endlessboomcapitalism@gmail.com - 2016-06-27 11:05 -0700

csiph-web