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

Groups > comp.lang.forth > #47022 > unrolled thread

Looking for some help with this gforth program. Thanks!

Back to article view | Back to comp.lang.forth

Contents

  Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 13:54 -0700
    Re: Looking for some help with this gforth program. Thanks! all2001@spambog.com (Wolfgang Allinger) - 2016-05-11 17:59 -0300
      Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-11 19:16 -0700
        Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 19:40 -0700
          Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-11 23:22 -0700
            Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-12 00:01 -0700
              Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-12 00:08 -0700
                Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-12 12:09 -0700
              Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-12 20:48 -0400
                Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-12 18:04 -0700
                  Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-12 21:21 -0400
                  Re: Looking for some help with this gforth program. Thanks! Cecil Bayona <cbayona@cbayona.com> - 2016-05-12 20:27 -0500
                    Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-12 18:46 -0700
                      Re: Looking for some help with this gforth program. Thanks! Cecil Bayona <cbayona@cbayona.com> - 2016-05-12 23:28 -0500
                        Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-13 00:52 -0700
                          Re: Looking for some help with this gforth program. Thanks! Pablo Hugo Reda <pabloreda@gmail.com> - 2016-05-13 04:07 -0700
                          Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-14 00:42 -0400
                            Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-14 00:05 -0700
                              Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-15 00:10 -0400
                                Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-15 10:34 +0000
                                  Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-15 09:43 -0400
                                    Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-16 12:21 +0000
                                      Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-16 07:38 -0700
                                        Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-16 14:56 +0000
                                      Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-16 12:07 -0400
                                      Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-16 09:18 -0700
                                      Re: Looking for some help with this gforth program. Thanks! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-16 13:19 -0500
                                        Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-17 12:39 +0000
                                          Re: Looking for some help with this gforth program. Thanks! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-17 10:34 -0500
                                            Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-17 15:54 +0000
                                              Re: Looking for some help with this gforth program. Thanks! mhx@iae.nl - 2016-05-17 12:44 -0700
                                  Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-15 11:03 -0700
                                    Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-15 21:56 -0400
                                      Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-15 19:02 -0700
                                        Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-15 20:03 -0700
                                        Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-16 02:13 -0400
                                          Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-16 00:37 -0700
                                            Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-16 13:41 +0000
                                              Re: Looking for some help with this gforth program. Thanks! Bernd Paysan <bernd.paysan@gmx.de> - 2016-05-16 21:42 +0000
                                                Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-16 16:23 -0700
                                                Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-16 16:41 -0700
                                                  Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-16 20:32 -0700
                                                  Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-16 20:47 -0700
                                                  Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-17 06:32 +0000
                                                    Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-17 07:56 -0700
                                                  Re: Looking for some help with this gforth program. Thanks! Bernd Paysan <bernd.paysan@gmx.de> - 2016-05-17 23:05 +0000
                                                    Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-17 21:16 -0700
                                                      Re: Looking for some help with this gforth program. Thanks! Bernd Paysan <bernd.paysan@gmx.de> - 2016-06-04 22:44 +0000
                                                Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-17 13:42 +0000
                                                  Re: Looking for some help with this gforth program. Thanks! Bernd Paysan <bernd.paysan@gmx.de> - 2016-05-17 22:31 +0000
                                                    Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-18 16:43 +0000
                                        Re: Looking for some help with this gforth program. Thanks! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-16 10:38 -0500
                                          Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-16 10:10 -0700
                                            Re: Looking for some help with this gforth program. Thanks! Cecil Bayona <cbayona@cbayona.com> - 2016-05-16 12:29 -0500
                                            Re: Looking for some help with this gforth program. Thanks! Cecil Bayona <cbayona@cbayona.com> - 2016-05-16 12:34 -0500
                                            Re: Looking for some help with this gforth program. Thanks! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-16 13:27 -0500
                                              Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-17 16:11 -0700
                                                Re: Looking for some help with this gforth program. Thanks! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-18 04:31 -0500
                                        Re: Looking for some help with this gforth program. Thanks! Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-16 18:46 +0000
                            Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-14 00:07 -0700
                              Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-14 00:20 -0700
                                Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-14 01:23 -0700
                                  Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-15 00:13 -0400
                                    Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-14 21:55 -0700
    Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-11 17:08 -0700
      Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 17:40 -0700
        Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 18:54 -0700
          Re: Looking for some help with this gforth program. Thanks! Doug Hoffman <glidedog@gmail.com> - 2016-05-13 06:55 -0400
            Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-13 11:07 -0700
            Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-13 20:42 -0700
              Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-13 20:57 -0700
              Re: Looking for some help with this gforth program. Thanks! Doug Hoffman <glidedog@gmail.com> - 2016-05-14 05:54 -0400
                Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-14 15:20 -0700
                  Re: Looking for some help with this gforth program. Thanks! Doug Hoffman <glidedog@gmail.com> - 2016-05-15 05:45 -0400
                    Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-15 11:21 -0700
                      Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-15 11:39 -0700
      Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-11 20:45 -0700
        Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-11 23:05 -0700
          Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 23:15 -0700
            Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-12 22:34 -0400
        Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 23:11 -0700
    Re: Looking for some help with this gforth program. Thanks! november.nihal@gmail.com - 2016-05-11 19:00 -0700
      Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 19:14 -0700
    Re: Looking for some help with this gforth program. Thanks! humptydumpty <ouatubi@gmail.com> - 2016-05-12 01:48 -0700
      Re: Looking for some help with this gforth program. Thanks! Doug Hoffman <glidedog@gmail.com> - 2016-05-12 07:43 -0400
        Re: Looking for some help with this gforth program. Thanks! humptydumpty <ouatubi@gmail.com> - 2016-05-12 10:21 -0700
      Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-12 12:11 -0700
    Re: Looking for some help with this gforth program. Thanks! "Ala'a" <amalawi@gmail.com> - 2016-05-12 14:34 -0700
      Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-12 16:20 -0700
    Re: Looking for some help with this gforth program. Thanks! Marcos Cruz <use_the_contact_page@programandala.net> - 2016-05-14 12:27 +0000
    Re: Looking for some help with this gforth program. Thanks! "WJ" <w_a_x_man@yahoo.com> - 2016-05-16 05:35 +0000

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#47228

Bernd Paysan <bernd.paysan@gmx.de> writes:
> If progress on hardware stops (e.g.  because Moore's law hits the
> physical limits), then it will be more important to optimize better.
> This will consume more time, and require more talented developers, so
> maybe there will be some layoffs.

Rather the opposite, it will bring back the hierarchy of "systems
analysists", "programmer analysts", and "coders" that traditionally did
100-person multi-year projects that accomplish what someone does bangs
out these days in one afternoon.

There's a good book from the 1980s about search engine implementation.
It has all kinds of info about how to optimize bit layouts of search
indexes on disk and stuff like that.  I'm sure engineers at places like
Google still read this book.  It takes a lot of careful coding and
optimization to do that stuff efficiently.  The book's title: "Managing
Gigabytes".

Gigabytes today are of course something you simply slurp into RAM from a
Python script and crunch with built-in library functions.  You might get
a 10x efficiency hit but you don't care.  If you change the title to
"Managing Petabytes" though, most of the stuff in the book is still
valid.

[toc] | [prev] | [next] | [standalone]

#47233

Thanks Anton, for bringing up "The Mythical Man Month". I just finished reading it for the first time and I'd have to say "WOW!!! Somethings seem to never change." LOL!!!  It does have a lot good advice for a novice like me, even if it's over 40 years old.

[toc] | [prev] | [next] | [standalone]

#47234

Thanks Paul, I'll have to look it up some time. Right now, I'm still learning the basics, so I have enough on my plate. I did finish reading the "Mythical Man Month" and boy I really enjoyed it. I think it had some good information about documenting, that I'm sure to review again and again on my programming adventures. Take care now.

[toc] | [prev] | [next] | [standalone]

#47237

Paul Rubin <no.email@nospam.invalid> writes:
>There's a good book from the 1980s about search engine implementation.
>It has all kinds of info about how to optimize bit layouts of search
>indexes on disk and stuff like that.  I'm sure engineers at places like
>Google still read this book.  It takes a lot of careful coding and
>optimization to do that stuff efficiently.  The book's title: "Managing
>Gigabytes".
>
>Gigabytes today are of course something you simply slurp into RAM from a
>Python script and crunch with built-in library functions.  You might get
>a 10x efficiency hit but you don't care.  If you change the title to
>"Managing Petabytes" though, most of the stuff in the book is still
>valid.

The primordial edition (with one author exchanged) of "Managing
Gigabytes" was called "Text Compression" (from 1990), and it is
extremely good.  Apparently their update (1st ed. 1994, 2nd ed. 1999)
needed a snappier, if less timeless title.

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

[toc] | [prev] | [next] | [standalone]

#47253

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> The primordial edition (with one author exchanged) of "Managing
> Gigabytes" was called "Text Compression" (from 1990)

No, Text Compression is a completely different book.  It is also very
good though.  There was indeed a new edition of Managing Gigabytes at
some point, but they didn't change the title.

[toc] | [prev] | [next] | [standalone]

#47266

Am Mon, 16 May 2016 16:41:37 -0700 schrieb Paul Rubin:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> If progress on hardware stops (e.g.  because Moore's law hits the
>> physical limits), then it will be more important to optimize better.
>> This will consume more time, and require more talented developers, so
>> maybe there will be some layoffs.
> 
> Rather the opposite, it will bring back the hierarchy of "systems
> analysists", "programmer analysts", and "coders" that traditionally did
> 100-person multi-year projects that accomplish what someone does bangs
> out these days in one afternoon.

I think this 1970 style development came from the enormous turnaround 
times of coding.  My father started doing programming in that time, and a 
coder simply sat on his code for a day, and submitted a stack of punch 
cards in the evening to receive a printout with the compiler errors the 
next day.

This caused productivity to go down a lot (compared to current mostly 
interactive development), and that requires many more people.  The bigger 
projects today use lots of less skilled people who all add layers and 
layers of abstractions to not deal with the actual problem; this makes 
the project large and bulky, as well as slow and buggy.  These people may 
fear layoff, because unlike the 1970s, they can't be used to get from an 
algorithm to actually compiling code in a week or two.

> There's a good book from the 1980s about search engine implementation.
> It has all kinds of info about how to optimize bit layouts of search
> indexes on disk and stuff like that.  I'm sure engineers at places like
> Google still read this book.  It takes a lot of careful coding and
> optimization to do that stuff efficiently.  The book's title: "Managing
> Gigabytes".
> 
> Gigabytes today are of course something you simply slurp into RAM from a
> Python script and crunch with built-in library functions.  You might get
> a 10x efficiency hit but you don't care.  If you change the title to
> "Managing Petabytes" though, most of the stuff in the book is still
> valid.

Maybe, but actually, Google just slurps in a Petabyte into RAM.  It's 
using a big farm with around 100k severs and each of them with enough 
gigabytes to slurp in a Petabyte or two.  The thing that matters more 
here is how to distribute the workload, i.e. map reduce.

If I would develop a distributed search engine, I would probably go that 
way: make different computers responsible for different key terms.  Terms 
are single words, or frequently occurring phrases.  There's a list of key 
terms and how frequent they are, and when you enter a search, it will 
address the computer who's responsible for the least frequent term in 
that search.  All this computer than has to do is to search for the next 
least frequent term in your query, and filter the results by the other, 
more frequent terms.  So a search for "when did margaret thatcher die" 
will ask the "thatcher" computer, who then searches for "die", because 
for him, "margaret" is a very frequent term. And "when did" are stop 
words, indicating only that there should be a date in the query result 
close to the search term. "die" is market as synonym for "†", so results 
with that sign will be looked up, too.

The result will turn up "April 8th, 2013" and a number of links to "the 
witch is dead", or, if there is a censorship regime "a number of search 
results are not available in your country; we are sorry about that".

The crawlers will index texts (i.e. split them into words and phrases, 
and figure out which words and phrases are most characteristic for that 
text) and distribute them to the responsible computers.  Of course, page 
rank and relevance algorithms are needed, too.  I probably would add a 
"good/bad" feedback button so that people can add further hints for the 
ranking algorithms.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#47270

Bernd Paysan <bernd.paysan@gmx.de> writes:
> I think this 1970 style development came from the enormous turnaround 
> times of coding....

Maybe, though the waterfall development model didn't help much either.

> actually, Google just slurps in a Petabyte into RAM.  It's using a big
> farm with around 100k severs and each of them with enough gigabytes to
> slurp in a Petabyte or two.

They are very very careful about data layouts though, so I wouldn't
consider that to be "slurping" in the sense of just gobbling all the
data in the simplest and most convenient way.  In particular, they use
quite intricate bit-packing encodings because while they have
gigabytes/petabytes of main ram, they want to get as much of the most
frequently accessed index data as possible into the very scarce cpu
cache space.

Aside: do you know if that 100k servers in a map/reduce cluster is an
accurate figure?  I'd been wondering about that.  I thought the
individual Google clusters were much smaller, like 10k servers, because
of their modular data center design (at least as of 2011 or so).  Of
course they have lots of such clusters.

> If I would develop a distributed search engine, I would probably go that 
> way: make different computers responsible for different key terms.  

That's called horizontal sharding and it's a standard technique.

> I probably would add a "good/bad" feedback button so that people can
> add further hints for the ranking algorithms.

I'm sure google is way beyond that by now.  As the saying goes, they
know more about you and your preferences than you yourself know ;-).

[toc] | [prev] | [next] | [standalone]

#47828

Am Tue, 17 May 2016 21:16:33 -0700 schrieb Paul Rubin:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> I think this 1970 style development came from the enormous turnaround
>> times of coding....
> 
> Maybe, though the waterfall development model didn't help much either.
> 
>> actually, Google just slurps in a Petabyte into RAM.  It's using a big
>> farm with around 100k severs and each of them with enough gigabytes to
>> slurp in a Petabyte or two.
> 
> They are very very careful about data layouts though, so I wouldn't
> consider that to be "slurping" in the sense of just gobbling all the
> data in the simplest and most convenient way.  In particular, they use
> quite intricate bit-packing encodings because while they have
> gigabytes/petabytes of main ram, they want to get as much of the most
> frequently accessed index data as possible into the very scarce cpu
> cache space.

They like protobuf encoding, which is compact and fast to "parse".  I 
took protobuf as primary inspiration of the net2o command language (which 
is for commands and structural data, just as protobuf).

Text compression algorithms also help, because the way they work, they 
actually create something that is easier to search than the uncompressed 
text: You turn the text into a dictionary+references into that 
dictionary, including phrases.

> Aside: do you know if that 100k servers in a map/reduce cluster is an
> accurate figure?  I'd been wondering about that.  I thought the
> individual Google clusters were much smaller, like 10k servers, because
> of their modular data center design (at least as of 2011 or so).  Of
> course they have lots of such clusters.

Google has 13 datacenters, and 900k servers in total (in 2013):

https://storageservers.wordpress.com/2013/07/17/facts-and-stats-of-worlds-
largest-data-centers/

So it's a bit less than 100k servers per data center, but the order of 
magnitude is right.  This is not just search engine, but also ad servers, 
and storage for gmail, photos, google+ postings and other could stuff.  I 
don't think you can really separate that stuff out, because Gmail and 
Google+ are searchable, too, and photos are part of the image search, so 
while those are different products on the frontend, the backend is the 
same.

>> If I would develop a distributed search engine, I would probably go
>> that way: make different computers responsible for different key terms.
> 
> That's called horizontal sharding and it's a standard technique.

Yes.

>> I probably would add a "good/bad" feedback button so that people can
>> add further hints for the ranking algorithms.
> 
> I'm sure google is way beyond that by now.  As the saying goes, they
> know more about you and your preferences than you yourself know ;-).

That's not limited to Google... it amplifies the "filter bubble" effect 
people have anyways.  Facebook's timeline looks quite different for 
liberal and conservative users.  When you see only those part of the 
world which you agree to, you think your view is the majority view, and 
the other views are fringe or non-existent.

That thing is dangerous...

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#47250

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Am Mon, 16 May 2016 13:41:24 +0000 schrieb Anton Ertl:
>> If hardware stops offering
>> more resources, I wonder how long the software industry will progress
>> further, or if, say, 10 years later, all worthwhile programs for using
>> the now-fixed hardware are written, and the software industry will see
>> huge layoffs.
>
>Software developers will use all available resources, because they are 
>lazy, and have the fastest machines.  If progress on hardware stops (e.g. 
>because Moore's law hits the physical limits), then it will be more 
>important to optimize better.  This will consume more time, and require 
>more talented developers, so maybe there will be some layoffs.

Will there be the money to fund such more optimized software projects?
If so, why is the money not there now?  In some cases, yes, it's not
there because for now it's more important to be the first to the
market, and the resources will be there when the product reaches the
masses.  But for others, maybe there is just no market that is large
enough to fund the optimized project, while at the lower costs of the
non-optimized project there is a market, if the hardware resources are
there.

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

[toc] | [prev] | [next] | [standalone]

#47265

Am Tue, 17 May 2016 13:42:26 +0000 schrieb Anton Ertl:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>Am Mon, 16 May 2016 13:41:24 +0000 schrieb Anton Ertl:
>>> If hardware stops offering more resources, I wonder how long the
>>> software industry will progress further, or if, say, 10 years later,
>>> all worthwhile programs for using the now-fixed hardware are written,
>>> and the software industry will see huge layoffs.
>>
>>Software developers will use all available resources, because they are
>>lazy, and have the fastest machines.  If progress on hardware stops
>>(e.g.
>>because Moore's law hits the physical limits), then it will be more
>>important to optimize better.  This will consume more time, and require
>>more talented developers, so maybe there will be some layoffs.
> 
> Will there be the money to fund such more optimized software projects?
> If so, why is the money not there now?

I think the money is already there now, in some areas where Moore's law 
had already hit the wall.  Think about Vulkan for GPUs - 2 decades we had 
OpenGL and an OpenGL-ripoff DirectX, and the GPUs and CPUs just got 
faster and faster, and the overhead of OpenGL didn't matter, because the 
balance was maintained.  Now, a few years ago, we hit the clock wall with 
the CPUs, while the GPUs still get faster, because they get more cores.  
What to do?  Especially AMD with its relatively slow single-thread 
performance had a big problem: The CPU side of OpenGL is single-threaded, 
and became a bottleneck.

What to do?  Create a new API which removes that bottleneck, can be multi-
threaded, and by using command buffers and mixing of compute and shader 
code in the GPU reduces the pressure on the CPU significantly.

I'd say that the resulting Vulkan driver is also easier to maintain, 
which is a good idea in difficult economic situations (the one AMD 
faces), too.  AMD is just pressed harder than its competitors, so they 
show the effect earlier.

> In some cases, yes, it's not
> there because for now it's more important to be the first to the market,
> and the resources will be there when the product reaches the masses. 
> But for others, maybe there is just no market that is large enough to
> fund the optimized project, while at the lower costs of the
> non-optimized project there is a market, if the hardware resources are
> there.

I think the main point is time-to-market.  If the resources grow, you can 
add new features, and the one who adds features faster is gaining market 
share (during the era, where Moore's law worked best, the winner is a 
company like Microsoft).  If your resources are stagnating, you can only 
add new features that need "more resources", if you optimize, i.e. if you 
use the available resources better.  Therefore, there is pressure to 
optimize, and to think about the problem and find the right architecture.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#47279

Bernd Paysan <bernd.paysan@gmx.de> writes:
>I think the main point is time-to-market.  If the resources grow, you can 
>add new features, and the one who adds features faster is gaining market 
>share (during the era, where Moore's law worked best, the winner is a 
>company like Microsoft).  If your resources are stagnating, you can only 
>add new features that need "more resources", if you optimize, i.e. if you 
>use the available resources better.

Yes.  But will the feature be considered to be worth the cost if the
cost is high because it requires optimization.  In some cases yes, but
the question is if there are enough such cases to support the software
industry at the same size.

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

[toc] | [prev] | [next] | [standalone]

#47201

Paul Rubin <no.email@nospam.invalid> wrote:
> rickman <gnuarm@gmail.com> writes:
>> We were discussing the suitability of the x86 processor.  Yes, I
>> generalized to any processor intended to run C, but a 6805
>> CPU.... really?  I don't think it was really designed to run C. 
> 
> I don't think the x86 was originally designed to run C either,
> particularly the original 16 bit versions.  Later updates and
> extensions made it much more C friendly.

Perhaps not C, but definitely PL/M.  The architectural differences
between the 8080 and the 8086 made it much easier to support high-
level languages and I'm sure that wasn't an accident.

Between the 8080 and the 8086 came the Z80.  The Z80 added proper
16-bit index registers to the 8080, the lack of which really hurt code
generation .  The 8086 had index registers too, and along with proper
16-bit arithmetic this was pretty much the complete feature set you
need for C.  So, OK, maybe the 8086 was not designed explicitly for C,
but definitely for languages with an Algol-style stack a la Randell
and Russell.

Andrew.

[toc] | [prev] | [next] | [standalone]

#47204

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> Perhaps not C, but definitely PL/M.

Oh yes, PL/M, cool.  I've been wanting to look into that sometime.  I
wonder if it got some things right that C messed up.

> Between the 8080 and the 8086 came the Z80.

And the 8085 ;-)

> The 8086 had index registers too, and along with proper 16-bit
> arithmetic this was pretty much the complete feature set you need for C.

I think the first real intentional C machine was Dave Ditzel's CRISP.
But, I don't remember what deficiencies (from a C perspective) in
earlier processors it tried to fix.

[toc] | [prev] | [next] | [standalone]

#47205

On 5/16/2016 12:10 PM, Paul Rubin wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> Perhaps not C, but definitely PL/M.
>
> Oh yes, PL/M, cool.  I've been wanting to look into that sometime.  I
> wonder if it got some things right that C messed up.
>
>> Between the 8080 and the 8086 came the Z80.
>
> And the 8085 ;-)
>
>> The 8086 had index registers too, and along with proper 16-bit
>> arithmetic this was pretty much the complete feature set you need for C.
>
> I think the first real intentional C machine was Dave Ditzel's CRISP.
> But, I don't remember what deficiencies (from a C perspective) in
> earlier processors it tried to fix.
>
We used PLM on several ISIS development systems, way back and it was not 
bad, the language itself was pretty much stripped down to bare 
essentials, and it generated decent code. A lot of memories there, we 
were developing 8080 then later 8085 code on it, but the bulk was in 
assembler.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#47206

On 5/16/2016 12:10 PM, Paul Rubin wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> Perhaps not C, but definitely PL/M.
>
> Oh yes, PL/M, cool.  I've been wanting to look into that sometime.  I
> wonder if it got some things right that C messed up.
>
>> Between the 8080 and the 8086 came the Z80.
>
> And the 8085 ;-)
>
>> The 8086 had index registers too, and along with proper 16-bit
>> arithmetic this was pretty much the complete feature set you need for C.
>
> I think the first real intentional C machine was Dave Ditzel's CRISP.
> But, I don't remember what deficiencies (from a C perspective) in
> earlier processors it tried to fix.
>
You use to be able to get an emulator, with ISIS, PLM, and the Intel 
assembler and other tools on the Internet for free, I'm not sure if you 
still can, but I aught to secure a copy just for old time sake.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#47213

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> Perhaps not C, but definitely PL/M.
> 
> Oh yes, PL/M, cool.  I've been wanting to look into that sometime.  I
> wonder if it got some things right that C messed up.
> 
>> Between the 8080 and the 8086 came the Z80.
> 
> And the 8085 ;-)

'Twas the same thing, except in one chip rather than three.  (The 8085
was essentially the 8080A, plus the 8224 and 8288.)

>> The 8086 had index registers too, and along with proper 16-bit
>> arithmetic this was pretty much the complete feature set you need for C.
> 
> I think the first real intentional C machine was Dave Ditzel's
> CRISP.

Before SPARC?

> But, I don't remember what deficiencies (from a C perspective) in
> earlier processors it tried to fix.

I do: I wrote software tools for the thing!  One key difference was
that you could take the address of a register, which made returning
more than one value from a call a hack of a lot easier.  The other
thing was that you could effectively get a new set of registers just
by pushing the stack.  So calling was super-clean.

Andrew.

[toc] | [prev] | [next] | [standalone]

#47267

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> I think the first real intentional C machine was Dave Ditzel's
>> CRISP.
> Before SPARC?

Hmm, checking Wikipedia it seems they were contemporaneous.  For some
reason I thought CRISP was earlier.

> One key difference was that you could take the address of a register,
> which made returning more than one value from a call a hack of a lot
> easier.  The other thing was that you could effectively get a new set
> of registers just by pushing the stack.  So calling was super-clean.

Was there a conventional register file on the die, and if yes, did they
have to do a bunch of contortions to shuffle registers to memory etc.?
I'm assuming this worked with the very deep stacks typical of C
programs.

[toc] | [prev] | [next] | [standalone]

#47272

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> I think the first real intentional C machine was Dave Ditzel's
>>> CRISP.
>> Before SPARC?
> 
> Hmm, checking Wikipedia it seems they were contemporaneous.  For some
> reason I thought CRISP was earlier.
> 
>> One key difference was that you could take the address of a register,
>> which made returning more than one value from a call a hack of a lot
>> easier.  The other thing was that you could effectively get a new set
>> of registers just by pushing the stack.  So calling was super-clean.
> 
> Was there a conventional register file on the die, and if yes, did
> they have to do a bunch of contortions to shuffle registers to
> memory etc.?  I'm assuming this worked with the very deep stacks
> typical of C programs.

Yes, there was a register file, but it was managed automatically as a
cache of the top of the stack.  It wasn't not all that very different
in principle from the register windows of SPARC or Itanium.  It did
make for very clean code generation, and a super-clean enter/leave
call.  Also, IIRC there were stack instructions which could be used
for evaluationg expressions.

Andrew.

[toc] | [prev] | [next] | [standalone]

#47216

On 2016-05-16, Paul Rubin <no.email@nospam.invalid> wrote:
> rickman <gnuarm@gmail.com> writes:
>> We were discussing the suitability of the x86 processor.  Yes, I
>> generalized to any processor intended to run C, but a 6805
>> CPU.... really?  I don't think it was really designed to run C.
>
> I don't think the x86 was originally designed to run C either,
> particularly the original 16 bit versions.  Later updates and extensions
> made it much more C friendly.

I've here this book of Stephen Morse (architect of the 8086) "the 8086
primer" 0-8104-5165-4 , written about 1980, well before 32 bits i86
arrives.
It contains a chapter about "High level language programming"
It mentions COBOL, BASIC FORTRAN and PASCAL. Then it goes on about
high language programming with Intel's PL/M as an example of how much
better it is than assembler. So the claim is implicit that the 8086
was suitable for high level languages. Then there is the existance
of instruction like return-and-pop-the-return stack, which hints
to a call mechanism were you put parameters on the stack, then
let the callee remove them. This is an instruction I would not
likely use in an assembler program, but is a natural for a c-compiler.

Do you remember the bizarre arrangement that if you access data
through BP it is located in the stack segment, and via SI
in the data segment? This is a likely trap to the assembler
programmer to fall in.
Morse sells this as an advantage in chapter 2 : 8086 machine
organisation. "This use as a stack segment as a "data area" has
certain advantages [...] for the implementation of high level
languages." All those segments are a pain in the ass, but at least
a compiler will keep track of it fairly easy and enlarge the
accessable memory in the meantime.

IMHO Intel kind of reinvented C with this PL/M, but C was much
better in trying to shoot the same ducks. So I wouldn't be surprised if
it is intentional in order to not educate the reader to the existance
of C that C is not at all mentionned in this chapter.

C goes the other way. First define useful abstraction. Then let the
compiler writer care about cumbersome aspects of the processor,
lie small PIC or the 8052. That is the proper way, I would think.

Groetjes Albert

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#47113

Sorry my mistake. I meant Beaglebone. :)

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.forth

csiph-web