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


Groups > comp.lang.forth > #48505

Re: Kilocore

From anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups comp.lang.forth
Subject Re: Kilocore
Date 2016-06-25 14:10 +0000
Organization Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID <2016Jun25.161016@mips.complang.tuwien.ac.at> (permalink)
References (3 earlier) <nkhgdu$stn$1@dont-email.me> <2016Jun24.122108@mips.complang.tuwien.ac.at> <nkjk3r$9g9$1@dont-email.me> <2016Jun24.175754@mips.complang.tuwien.ac.at> <nkjmvn$kcf$1@dont-email.me>

Show all headers | View raw


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?

>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.

>> And for the software provider: Will the hardware maker actuallt build
>> the thing?  Will anyone buy it?  Once they buy it, will they buy my
>> software?
>
>What???  Who won't build a chip if you pay them?

Why should a software maker pay huge sums for building a new chip
based on untried principles?

>The software and 
>hardware are being designed by the same company.

There may be such hardware, but the KiloCore or GA are obviously not
among them.

>> If you want to get some idea of the issues, read what John Dallman has
>> written over the years about Itanium on comp.arch.
>
> From what I read the failure was in the software being able to be 
>optimized by the software tools.

Yes, that was part of it.  Although piecing together his postings
paints a broader picture.  E.g., this week he posted that HP suing
Oracle to force them to continue supporting the Itanium ensured that
John Dallman's company would not resume supporting it even if HP gave
them money (at least not the way the contracts were written).

>They took a leap of faith and it fell 
>short.

Yes.  And the sank billions of dollars in it, not just half a million.

The KiloCore people are also taking a leap of faith.  Given that it is
a research project, that's their job.

>> Supposedly you can use
>> some cores for producing a video signal.  I could imagine that one
>> could use it for an oscilloscope.  I don't know how much additional
>> circuitry would be needed and if it has any advantages over other
>> potential solutions for that application.
>
>Lol, "video signal" in the sense of a minimal resolution text display I 
>think.  I haven't seen anything more sophisticated being done.  Sure, 
>anything is conceivable, but getting it done is very hard with the GA144.
>
>I looked very hard at using the GA144 for an oscilloscope and the big 
>issue is the memory interface being very limited along with the very 
>limited memory in the chip.

Ok, it looks like you have looked into the possibilities of this chip
quite a lot, and if you did not find an application, I am unlikely to
find them, either.  I wonder what they sold to their investors.

>  But there is no high speed USB capability so it need a separate 
>interface chip which would be another MCU in reality.  At some point 
>adding hardware to make up for the limitations of the GA144 becomes not 
>unlike the story of "stone soup".

Sure, if you use it in an FPGA (or was it FPPA?) like capacity, it
won't stand on its own.  Of course, the question is if it contributes
enough to pay for itself.  Also, in this age of SoCs, you want to be
able to integrate it with all the other stuff on one chip, and I doubt
that this is easily possible given that Chuck Moore does not use
standard tools, and probably only the last stage of standard
interchange file formats.

- 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