public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Артем Шинкаров" <artyom.shinkaroff@gmail.com>
To: gcc <gcc@gcc.gnu.org>
Subject: GSoC 2010 Project Idea
Date: Sun, 28 Mar 2010 22:47:00 -0000	[thread overview]
Message-ID: <979659581003281437k3eab3771sdbafe2574a374e0d@mail.gmail.com> (raw)
In-Reply-To: <979659581003280414o8a88c0fy29016c15674834df@mail.gmail.com>

Hi,

I have a project in mind which I'm going to propose to the GCC in terms of
Google Summer of Code. My project is not on the list of project ideas
(http://gcc.gnu.org/wiki/SummerOfCode) that is why it would be very interesting
for me to hear any opinions and maybe even to find a mentor.


1. Project idea

A brief project idea is to create an abstract layer for vectorized
computations. This would allow to write a portable vectorized code.


2. State of the art

Nowadays most of processors have a support for SIMD computations. However, the
problem is that each hardware has a different set of SIMD instructions: Intel
MMX+SSE+AVX, PowerPC Altivec, ARM iWMMXt, and so on. GCC supports most of
architecture-specific instructions providing built-in functions. It is
considerably convenient to use these functions when you want to optimize some
piece of code. The problem starts when you want to make this code portable.
It is not a very common task, and of course GCC has a vectorizer.
Unfortunately, there are many examples which show that it is relatively simple
for a human to find a right  place in the code and vectorize it, but it is
extremely hard for the compiler to do the same. As a result we end up with the
code which is not using the capabilities of the architecture.
It would be much easier for the programmer to use an abstract layer to
implement a vectorized code. A compiler should deal with the portability issues
dispatching the code from the abstract layer to the particular architecture. My
experience shows that there are no such a library for C/C++ that could solve
the problem. There are some attempts like: http://libsimd.sourceforge.net/ but
it is only a small part of the idea, and unfortunately the development is
suspended. Or maybe I am wrong and everything is already written?


3. Implementation

First we need to introduce the SIMD abstract model functionality which can be
mapped  to the set of architectures we want to support. The difficulty is that
SIMD instruction sets from different architectures are not fully compatible.
Then we want to write a set of "fake-SIMD" functions to be sure that our code
will be usable within the architecture without SIMD support.
After that there is a question how to dispatch functions from the abstract
layer to the architecture layer. The trivial thing to do is just to map the
abstract layer functions to the built-in functions. Obviously it would not give
the best performance. For example, loading the data from the unaligned memory
into the SIMD register is much slower than loading the data from the aligned
memory. Altivec has an instruction vec_madd(a,b,c) which can be represented by
two instructions in SSE case: _mm_add_ps( _mm_mul_ps(a,b), c). It means that
some code optimizations are required.


4. Time constraints

The GSoC gives 4 month to finish the project. It means that the
timeline could be the following:
2 weeks -- discussions and design
1 week  -- fake SIMD
3 weeks -- implementation of the main dispatcher
2 weeks -- benchmarks and testing
* the first submission
1.5 month -- architecture specific dispatcher optimizations
0.5 month  -- testing
* the second submission

This project can be continued in various ways:
1) Cost model for the dispatcher
2) Auto vectorizer + dispatcher
3) Integration with other languages
And so on


5. Questions

Should it be the library or the part of the language? What about the extensions
of this abstract layer with a respect to the Larrabee (or similar) which
provides 512-bit register for vectorized operations? And so on.
These questions should be discussed considering the project time constraints
and the interest of the GCC. If anybody is interested in mentoring such a
project please let me know and I would be happy to discuss all the issues. If
anybody thinks that the project is hopeless, please let me know as well.

--
Best regards,
Artem Shinkarov
Compiler Technology and Computer Architecture Group
University of Hertfordshire

       reply	other threads:[~2010-03-28 21:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <979659581003280414o8a88c0fy29016c15674834df@mail.gmail.com>
2010-03-28 22:47 ` Артем Шинкаров [this message]
2010-03-30  8:33   ` Andi Kleen
2010-03-30 13:16   ` Joseph S. Myers
2010-03-30 17:03     ` Артем Шинкаров
2010-03-30 18:13   ` Michael Meissner
2010-04-11 20:46   ` Dorit Nuzman

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=979659581003281437k3eab3771sdbafe2574a374e0d@mail.gmail.com \
    --to=artyom.shinkaroff@gmail.com \
    --cc=gcc@gcc.gnu.org \
    /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).