From: "Michael V. Zolotukhin" <michael.v.zolotukhin@gmail.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Marek Polacek <polacek@redhat.com>,
Kirill Yukhin <kirill.yukhin@gmail.com>,
Richard Henderson <rth@redhat.com>,
gcc-patches@gcc.gnu.org, triegel@redhat.com
Subject: Re: [RFC] Offloading Support in libgomp
Date: Sun, 15 Sep 2013 12:51:00 -0000 [thread overview]
Message-ID: <20130915093007.GA60139@msticlxl57.ims.intel.com> (raw)
In-Reply-To: <20130914192956.GI1817@tucnak.redhat.com>
Hi Jakub,
This patch looks ok for me in general, but I am a bit worried about using
splay-trees. Couldn't we end up with their worst case linear performance
instead desired log?
Imagine the following scenario:
#pragma parallel ... // to produce N-threads
{
# pragma target map (i1, i2, ...iK)
{
// some code to offload using i1, i2, ... iK
}
}
Libgomp will start N-1 new threads, and all of them would want to look up
mappings for i1,i2,...iK in the splay tree. The first one wouldn't find
anything and would map and insert all the values to the tree. But the following
ones would look-up these addresses in the exactly same order, which will lead to
totally unbalanced tree.
Am I missing anything or is it a real problem?
Thanks, Michael
> Jakub
next prev parent reply other threads:[~2013-09-15 9:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130826141117.GF21876@tucnak.zalov.cz>
[not found] ` <20130827112609.GA4093@msticlxl57.ims.intel.com>
[not found] ` <20130827113956.GH21876@tucnak.zalov.cz>
[not found] ` <20130827115538.GB4093@msticlxl57.ims.intel.com>
[not found] ` <20130828093428.GO21876@tucnak.zalov.cz>
[not found] ` <20130910150126.GA2059@msticlxl57.ims.intel.com>
[not found] ` <20130910151453.GB1817@tucnak.redhat.com>
[not found] ` <20130910153053.GB2059@msticlxl57.ims.intel.com>
[not found] ` <20130910153624.GD1817@tucnak.redhat.com>
[not found] ` <20130910153810.GC2059@msticlxl57.ims.intel.com>
[not found] ` <20130913112930.GC30181@msticlxl57.ims.intel.com>
[not found] ` <20130913123614.GB1817@tucnak.redhat.com>
[not found] ` <20130913131109.GD30181@msticlxl57.ims.intel.com>
[not found] ` <20130913131556.GD1817@tucnak.redhat.com>
2013-09-13 16:19 ` Jakub Jelinek
2013-09-13 16:22 ` Marek Polacek
2013-09-15 9:12 ` Jakub Jelinek
2013-09-15 12:51 ` Michael V. Zolotukhin [this message]
2013-09-15 18:15 ` Michael V. Zolotukhin
2013-09-16 7:17 ` Jakub Jelinek
2013-09-16 7:18 ` Michael V. Zolotukhin
2013-09-16 8:07 ` Jakub Jelinek
2013-09-16 8:19 ` Michael V. Zolotukhin
2019-12-07 14:23 ` Thomas Schwinge
2019-12-18 17:16 ` Thomas Schwinge
2014-12-22 18:33 ` Thomas Schwinge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130915093007.GA60139@msticlxl57.ims.intel.com \
--to=michael.v.zolotukhin@gmail.com \
--cc=39@msticlxl57.ims.intel.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=kirill.yukhin@gmail.com \
--cc=polacek@redhat.com \
--cc=rth@redhat.com \
--cc=triegel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).