Re: How to write optimized code for an instruction set not supported by my computer?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, Nov 08, 2015 at 04:54:45PM -0600, Mario Castelán Castro wrote:
> <tomas@tuxteam.de> writes:
> >This link might be relevant:
> >
> > <http://superuser.com/questions/453786/how-do-i-get-avx-support-in-qemu>
> >
> >Besides Intel's Software Development Emulator, which seems to have pretty
> >burdensome license terms (on a superficial read -- it seems you have to
> >download the whole gorilla to just read the license, duh) it seems that
> >Bochs is the way to go?
>
> I have encountered that superuser.com question previously. It does
> not really provide a solution. It mentions an experimental extension
> to QEMU (an old version of QEMU) that implements some AVX
> instructions. I am wary of software like that. It seems to be done
> more as a proof of concept and as an exercise than a something
> intended for "production" usage.
This was my take-away from there too: *if* anything is worth trying,
then Bochs (unless mumble mumble Intel -- but their license texts
would scare *me* away. And then people complain about GPL... but
I disgress).
> QEMU does not support AVX as far as I know.
>
> The problem with Bochs and multithreading that I was referring to is
> that although the OS can handle multiple threads just as well on a
> single core system than on a multiple core system, the threads won't
> run on parallel; that has effects on performance which are not
> present on a real multithreaded systems, and those effects should be
> accounted for when tunning for performance.
I see. But a soft emulation won't give you an idea of performance
anyway? Just thinking about the whole mess from caching down to
instruction set (all of which the emulator has wildly different
timings for)... I'd guess that the single/multi-thread issue is
just a ripple in a sea of uncertainty.
I think expecting just a guess for the timings from an emulator
(at least at this level) is too much. You'd be better off with
your back-of-theenvelope calculations (and then testing, once you
get your hands on "real" hardware).
[...]
> No, I am not willing to use Intel's proprietary tools. In an earlier
> message in the same thread I said that I avoid proprietary software.
> That is one of the reasons of why I use Debian: It is easy to avoid
> the proprietary software.
Phew ;-)
regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlZAWzQACgkQBcgs9XrR2kZxxACeLd9MjnsbjtzVj+8N+wJlwIaW
v+8AoIH/eX9yY1j1IIck41FIJajZTxUI
=Jc6I
-----END PGP SIGNATURE-----
Reply to: