From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen)
To: OneSoul <onesoul@autistici.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Qemu + CUDA: a new possible way?
Date: Fri, 5 Jun 2009 16:59:28 -0400 [thread overview]
Message-ID: <20090605205928.GC22847@csclub.uwaterloo.ca> (raw)
In-Reply-To: <4A297B77.8080008@autistici.org>
On Fri, Jun 05, 2009 at 09:09:27PM +0100, OneSoul wrote:
> I'm a Qemu user for a long time and I'm very satisfied by its features
> of flexibility, power and portability - really a good project!
>
> Recently, reading some technical articles over internet, I have
> discoverd the big potentialities of the CUDA framework in relation to
> the scientific and graphic computing that takes strong advantage from
> the most recent GPUs. Someone has used it for password recovery,
> realtime rendering, etc, with great results.
>
> It would be possible to use this technology in the Qemu project to
> achieve better performance?
> It could be a significative step for the develop in virtualization
> technology?
>
> Someone, for example, in experimental way, has (re)wrote the md-raid
> kernel modules using the CUDA framework to accelerate the reed-solomon
> features... and it seems that works fine.
> Why not for Qemu or related components?
>
> The main question is about the dynamic transaltion engine: can it be
> modified for this framework?
> Someone says that Qemu is NOT parallelizable... but it seems strange
> because by definition is "Fast and Portable".
> Not portable on this framework?
> Pay attention, the computing on GPU is driven through a kernel module,
> not directly.
>
> What do you think about this draft idea? It's just a proof-of-concept,
> but I hope to be useful.
>
> Any feedback is welcome...
Password cracking involves lots and lots of identical attemps with
different values. Trivial to make parallel.
md5 involves doing xor on lots of data. Trivial to make parallel.
Rendering involves calculating lots of pixels. Trivial to make parallel.
qemu is emulating a single CPU doing one thing at a time. That is
pretty much not parallel work. Now adding the threaded IO so device
emulation is done in parallel to the cpu emulation (which I believe is
currently happening) does make sense, but I don't think there is much
chance of making the cpu emulation and translation particularly parallel.
At best you might get one thread doing the translation and another doing
the actual execution of the translation. Nothing parallel in the range
needed to make cuda useful.
--
Len Sorensen
next prev parent reply other threads:[~2009-06-05 20:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-05 20:09 [Qemu-devel] Qemu + CUDA: a new possible way? OneSoul
2009-06-05 20:59 ` Lennart Sorensen [this message]
2009-06-05 21:31 ` Blue Swirl
2009-06-06 2:42 ` Paul Brook
-- strict thread matches above, loose matches on Subject: below --
2009-06-05 8:01 OneSoul
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=20090605205928.GC22847@csclub.uwaterloo.ca \
--to=lsorense@csclub.uwaterloo.ca \
--cc=onesoul@autistici.org \
--cc=qemu-devel@nongnu.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 NNTP newsgroup(s).