Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.42!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!74.125.64.80.MISMATCH!postnews.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 14 Jan 2012 19:15:36 -0600
Message-ID: <4F1228B7.1030907@SPAM.comp-arch.net>
Date: Sat, 14 Jan 2012 17:15:35 -0800
From: "Andy (Super) Glew" <andy@SPAM.comp-arch.net>
Reply-To: andy@SPAM.comp-arch.net
Organization: comp-arch.net
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
Newsgroups: comp.lang.forth,comp.sys.intel,comp.arch
Subject: Re: Can someone explain step by step how one avoid many conditional in forth as described in Moore Fourth essay?
References: <19111298.516.1326191150632.JavaMail.geo-discussion-forums@yqbu38> <4F0DC609.9020503@SPAM.comp-arch.net> <jepqn4$m6d$2@reader1.panix.com> <4F10733F.4040603@SPAM.comp-arch.net> <jeqvj3$mqj$1@reader1.panix.com>
In-Reply-To: <jeqvj3$mqj$1@reader1.panix.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 18
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-bjmx0MkKaHUw4K0Z5Zyw8zU8wINE0hvpw5VaDDTJ/tf5VgsulHPUUGpHoyRWijqgnuKoBFmbI7ozW3V!CdPv5DwrbYQShydqoFJ04XZlMPAlbPovJOaY5DWkL7sLeg3VwdfaHCVh8g5ZrL0=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 2335
Xref: x330-a1.tempe.blueboxinc.net comp.lang.forth:8875 comp.sys.intel:170 comp.arch:5437

On 1/13/2012 8:16 PM, Joe keane wrote:
> In article<4F10733F.4040603@SPAM.comp-arch.net>,
> Andy (Super) Glew<andy@SPAM.comp-arch.net>  wrote:
>> Problem is that eager threads seldom last long, so it is hard for eager
>> threads to overcome the cost of migrating to another core.
>
> Essentially creating a new thread, for every -branch-, falls into the
> 'that don't sound right'.

Nobody would seriously propose a new thread for every branch.

You would only consider eager threading for flakey branches, where you 
don't know which way they are going to go.  And won't know for a while.

Myself, I think non-threading approaches to eager execution are better. 
  E.g. the discussion of short forward branches - emit colde that 
computes both sides of such a hammock, with operations like Phi nodes to 
bring back rto a single dataflow.