i will try that - thx
Am 27.08.2015 um 17:29 schrieb Artyom Tarasenko:
On Tue, Jul 28, 2015 at 9:52 AM, Dennis Luehring wrote:
> (i've posted the question already on qemu-disc...@nongnu.org but was toled
> to better use this mailing list)
>
> i've prepared an Debian 7.8.0 image for SPARC64/qemu
On Wed, Aug 26, 2015 at 9:47 PM, Richard Henderson wrote:
> On 08/26/2015 09:17 AM, Artyom Tarasenko wrote:
>>
>> After some debugging I think it's caused by memory faults. On every
>> MMU miss / access fault
>> TB is re-translated multiple times till the faulting instruction is found.
>
>
> That
On Tue, Jul 28, 2015 at 9:52 AM, Dennis Luehring wrote:
> (i've posted the question already on qemu-disc...@nongnu.org but was toled
> to better use this mailing list)
>
> i've prepared an Debian 7.8.0 image for SPARC64/qemu emulation for C/C++
> development before-real-hardware big-endian/unalign
On 08/26/2015 10:54 PM, Dennis Luehring wrote:
Am 26.08.2015 um 21:47 schrieb Richard Henderson:
Anyway, this sort of setup is exactly what I did for Alpha. The PALcode
(hypervisor-ish) layer used for qemu looks nothing like the PALcode layer used
for real hardware.
can post your qemu paramet
Am 26.08.2015 um 21:47 schrieb Richard Henderson:
Anyway, this sort of setup is exactly what I did for Alpha. The PALcode
(hypervisor-ish) layer used for qemu looks nothing like the PALcode layer used
for real hardware.
can post your qemu parameters for installing/starting your alpha
emulatio
On 08/26/2015 09:17 AM, Artyom Tarasenko wrote:
After some debugging I think it's caused by memory faults. On every
MMU miss / access fault
TB is re-translated multiple times till the faulting instruction is found.
That shouldn't happen. Are you certain it's not multiple MMU misses/faults?
A
Hi Richard,
On Sun, Aug 23, 2015 at 2:41 AM, Richard Henderson wrote:
> On Aug 22, 2015 9:45 AM, Artyom Tarasenko wrote:
>> For my test case tcg-indirect brings more performance gain than for Dennis:
>>
>> git master: 18m31s
>> tcg-indirect: 16m50s
>> #undef USE_TCG_OPTIMIZATIONS: 14m18s
>
> Th
Am 22.08.2015 um 20:53 schrieb Artyom Tarasenko:
Compared with #undef USE_TCG_OPTIMIZATIONS , they are similar, yes.
Compared with vanilla master I get a more noticeable improvement.
my test suffering less from the Aurelien Jarno described Sparc32->x86_64
"translation" if you're still using de
On Aug 22, 2015 9:45 AM, Artyom Tarasenko wrote:
> For my test case tcg-indirect brings more performance gain than for Dennis:
>
> git master: 18m31s
> tcg-indirect: 16m50s
> #undef USE_TCG_OPTIMIZATIONS: 14m18s
Thanks. That's useful.
>
>
> JIT statistic, before starting the test:
> (qemu
On Sat, Aug 22, 2015 at 7:47 PM, Dennis Luehring wrote:
> Am 22.08.2015 um 18:45 schrieb Artyom Tarasenko:
>>
>> git master: 18m31s
>> tcg-indirect: 16m50s
>> #undef USE_TCG_OPTIMIZATIONS: 14m18s
>
>
> my results are not totaly different to yours - ~20-30% slowdown compared to
> #undef USE_TCG_OP
Am 22.08.2015 um 18:45 schrieb Artyom Tarasenko:
git master: 18m31s
tcg-indirect: 16m50s
#undef USE_TCG_OPTIMIZATIONS: 14m18s
my results are not totaly different to yours - ~20-30% slowdown compared
to #undef USE_TCG_OPTIMIZATIONS
Am 21.08.2015 um 17:47 schrieb Richard Henderson:
On 08/20/2015 11:05 PM, Dennis Luehring wrote:
>> > g++ src/pugixml.cpp -g -Wall -Wextra -Werror -pedantic -std=c++0x -c -MMD
-MP
>> >
>> > tcg-indirect: ~2:46.5
>> > qemu.org-git: ~2:51.2 (worst result)
>> > without-optimization: ~2:14.1 (best r
On 2015-08-21 08:47, Richard Henderson wrote:
> On 08/20/2015 11:05 PM, Dennis Luehring wrote:
> >> > g++ src/pugixml.cpp -g -Wall -Wextra -Werror -pedantic -std=c++0x -c
> >> > -MMD -MP
> >> >
> >> > tcg-indirect: ~2:46.5
> >> > qemu.org-git: ~2:51.2 (worst result)
> >> > without-optimization: ~2
On 08/20/2015 11:05 PM, Dennis Luehring wrote:
>> > g++ src/pugixml.cpp -g -Wall -Wextra -Werror -pedantic -std=c++0x -c -MMD
>> > -MP
>> >
>> > tcg-indirect: ~2:46.5
>> > qemu.org-git: ~2:51.2 (worst result)
>> > without-optimization: ~2:14.1 (best result)
>>
>> No compiler optimization? I would
Am 21.08.2015 um 07:49 schrieb Richard Henderson:
On 08/20/2015 09:32 PM, Dennis Luehring wrote:
> gcc prime.c -o prime.out -lm
>
> prime.out runtime
>
> tcg-indirect: ~9.3 sec (best result)
> qemu.org-git: ~11 sec
> without-optimization: ~9.9 sec (worst result)
I presume this is integer prime f
On 08/20/2015 09:32 PM, Dennis Luehring wrote:
gcc prime.c -o prime.out -lm
prime.out runtime
tcg-indirect: ~9.3 sec (best result)
qemu.org-git: ~11 sec
without-optimization: ~9.9 sec (worst result)
I presume this is integer prime factoring?
g++ src/pugixml.cpp -g -Wall -Wextra -Werror -ped
Am 20.08.2015 um 19:19 schrieb Richard Henderson:
This isn't surprising, because at the moment tcg optimizations are almost
completely ineffective for sparc. The way the register windows are implemented
means that there are very few proper tcg temporaries to optimize.
I've just updated an old b
Am 19.08.2015 um 16:41 schrieb Artyom Tarasenko:
And if I completely disable optimizer (// #define
USE_TCG_OPTIMIZATIONS in tcg.c), it's still quite faster:
real14m17.668s
user14m10.241s
sys 0m6.060s
my tests also without USE_TCG_OPTIMIZATIONS
qemu 2.4.50, netbsd 6.1.5 SPARC64
wi
On 08/19/2015 07:41 AM, Artyom Tarasenko wrote:
Without the patch:
time g++ -DHAVE_CONFIG_H -I. -I../binutils-gdb/gold
-I../binutils-gdb/gold -I../binutils-gdb/gold/../include
-I../binutils-gdb/gold/../elfcpp
-DLOCALEDIR="\"/usr/local/share/locale\""
-DBINDIR="\"/usr/local/bin\"" -DTOOLBINDIR=
On Thu, Aug 20, 2015 at 7:22 AM, Dennis Luehring wrote:
> Am 19.08.2015 um 16:41 schrieb Artyom Tarasenko:
>>
>> And if I completely disable optimizer (// #define
>> USE_TCG_OPTIMIZATIONS in tcg.c), it's still quite faster:
>>
>> real14m17.668s
>> user14m10.241s
>> sys 0m6.060s
>
>
> m
On 2015-08-19 12:41, Artyom Tarasenko wrote:
> Hi Richard,
>
> On Tue, Aug 18, 2015 at 7:55 PM, Richard Henderson wrote:
> > On 08/18/2015 02:24 AM, Artyom Tarasenko wrote:
> >> The unoptimized case is a sequence of multiple cmp and branch
> >> operations (likely created by a "case" statement in
Hi Richard,
On Tue, Aug 18, 2015 at 7:55 PM, Richard Henderson wrote:
> On 08/18/2015 02:24 AM, Artyom Tarasenko wrote:
>> The unoptimized case is a sequence of multiple cmp and branch
>> operations (likely created by a "case" statement in the original
>> source code), especially where cmp is in
Am 18.08.2015 um 21:06 schrieb Karel Gardas:
Thanks a lot for doing this. It looks like g++ is memory-bound in this
case, isn't it? What does stream[1] benchmark tell on host and
emulated as 32/64bit sparc binary? Let's see if the ratio is kind of
similar to the time you get...
[1]:https://www.c
On 08/18/2015 02:24 AM, Artyom Tarasenko wrote:
> The unoptimized case is a sequence of multiple cmp and branch
> operations (likely created by a "case" statement in the original
> source code), especially where cmp is in a delay slot of a branch
> instruction.
Interesting.
> I wonder whether we
Am 06.08.2015 um 11:00 schrieb Karel Gardas:
Denis, if NetBSD is fast in qemu and if it provides sparc64 user-land,
perhaps also its GCC is sparc64 binary and if so, then it would be
good if you do your original benchmark of compiling pugixml.cpp and
write the numbers here for comparison? I would
Am 18.08.2015 um 10:19 schrieb Aurelien Jarno:
How big is the source file and the output file? I find strange that I/O
impacts so much for a compilation which should be CPU bounded. Maybe try
to add the -pipe argument to g++.
and the gcc -ftime-report
g++ src/pugixml.cpp -g -Wall -Wextra -Werr
Am 18.08.2015 um 10:19 schrieb Aurelien Jarno:
How big is the source file and the output file? I find strange that I/O
impacts so much for a compilation which should be CPU bounded. Maybe try
to add the -pipe argument to g++.
NetBSD SPARC64, running from ramdisk, qemu 2.4.50
g++ src/pugixml.cp
On 2015-08-18 06:25, Dennis Luehring wrote:
> Am 06.08.2015 um 11:00 schrieb Karel Gardas:
> >Denis, if NetBSD is fast in qemu and if it provides sparc64 user-land,
> >perhaps also its GCC is sparc64 binary and if so, then it would be
> >good if you do your original benchmark of compiling pugixml.c
On Mon, Aug 3, 2015 at 11:17 AM, Aurelien Jarno wrote:
> On 2015-08-03 10:31, Artyom Tarasenko wrote:
>> Hi Aurelien,
>>
>> On Fri, Jul 31, 2015 at 5:43 PM, Aurelien Jarno wrote:
>>
>> >> > It uses a lot of integer functions
>> >> > based on CPU flags, so most of the time is spent computing them
On 2015-08-17 18:25, Artyom Tarasenko wrote:
> On Mon, Aug 17, 2015 at 5:40 PM, Richard Henderson wrote:
> > On 08/17/2015 07:19 AM, Artyom Tarasenko wrote:
> >> Well, on the other hand, every access goes via helper_check_align.
> >> There is a comment /* XXX remove alignment check */.
> >> I wond
On Mon, Aug 17, 2015 at 5:40 PM, Richard Henderson wrote:
> On 08/17/2015 07:19 AM, Artyom Tarasenko wrote:
>> Well, on the other hand, every access goes via helper_check_align.
>> There is a comment /* XXX remove alignment check */.
>> I wonder how this can be done in a more efficient way?
>
> N
On 08/17/2015 07:19 AM, Artyom Tarasenko wrote:
> Well, on the other hand, every access goes via helper_check_align.
> There is a comment /* XXX remove alignment check */.
> I wonder how this can be done in a more efficient way?
Not ever access does so. There are only 3 memory related calls to c
On Thu, Jul 30, 2015 at 9:55 AM, Aurelien Jarno wrote:
> On 2015-07-30 05:47, Dennis Luehring wrote:
>> so your aarch64 is just less todo for qemu - not EVERY >= 16bit memory
>> access needs swapping or needs check for unaligned access to emulate
>> bus-erros
>
> On recent Intel CPU, the byteswapp
Am 31.07.2015 um 17:43 schrieb Aurelien Jarno:
> >Anyway I have extracted this code into a C file (see attached file) that
> >can more easily compiled to 32 or 64 bit using -m32 or -m64. I observe
> >the same behavior than sysbench, even with qemu-user (which is not
> >surprising as the above cod
using (later) git qemu 2.3.93
~/qemu/sparc64-softmmu/qemu-system-sparc64 -m 1024 -nographic -monitor
telnet::4440,server,nowait -serial telnet::3000,server -hda
./netbsd-615-sparc64.raw -cdrom ./NetBSD-6.1.5-sparc64.iso -boot d -net
nic,model=i82551 -net user
gives me unlimited lines of (on
I use -net nic,model=i82551 -net user for OpenBSD, perhaps this will
also work for you? This is for Qemu 2.2.0 and whole command line
looks: /opt/qemu-2.2.0/bin/qemu-system-sparc64 -hda
openbsd_sparc64.img -m 1024 -nographic -net nic,model=i82551 -net
user
On Thu, Aug 6, 2015 at 11:27 AM, Dennis
Am 06.08.2015 um 11:21 schrieb Dennis Luehring:
if NetBSD is fast in qemu and if it provides sparc64 user-land,
>perhaps also its GCC is sparc64 binary and if so
according to the docs its pure SPARC64 kernel and userland (no exceptions)
i don't know nothing about NetBSD - network isn't working (or dhcp
inactive - i don't know), can't install wget etc. - so it will take some
time
Am 06.08.2015 um 11:00 schrieb Karel Gardas:
Denis, if NetBSD is fast in qemu and if it provides sparc64 user-land,
perhaps also its GCC is sparc64 b
Denis, if NetBSD is fast in qemu and if it provides sparc64 user-land,
perhaps also its GCC is sparc64 binary and if so, then it would be
good if you do your original benchmark of compiling pugixml.cpp and
write the numbers here for comparison? I would certainly appreciate it
since I'll not get to
Am 03.08.2015 um 17:59 schrieb Karel Gardas:
On Mon, Aug 3, 2015 at 4:51 PM, Dennis Luehring wrote:
> ok - NetBSD 6.5.1 SPARC64 is blasting fast compare to Debian 7.8.0 SPARC64 -
> i installed the complete system (without X) in a few minutes
> Debian needs >1h
I had the same experience with Ope
On Mon, Aug 3, 2015 at 4:51 PM, Dennis Luehring wrote:
> ok - NetBSD 6.5.1 SPARC64 is blasting fast compare to Debian 7.8.0 SPARC64 -
> i installed the complete system (without X) in a few minutes
> Debian needs >1h
I had the same experience with OpenBSD for sparc64, also fast to
install. The pro
Am 30.07.2015 um 10:55 schrieb Aurelien Jarno:
Note that when you say SPARC64 here, it's actually only the kernel, you
are using a 32-bit userland.
ok - NetBSD 6.5.1 SPARC64 is blasting fast compare to Debian 7.8.0
SPARC64 - i installed the complete system (without X) in a few minutes
Debian
On 2015-08-03 10:31, Artyom Tarasenko wrote:
> Hi Aurelien,
>
> On Fri, Jul 31, 2015 at 5:43 PM, Aurelien Jarno wrote:
>
> >> > It uses a lot of integer functions
> >> > based on CPU flags, so most of the time is spent computing them in
> >> > helper_compute_psr.
> >>
> >> I wonder if this can b
Hi Aurelien,
On Fri, Jul 31, 2015 at 5:43 PM, Aurelien Jarno wrote:
>> > It uses a lot of integer functions
>> > based on CPU flags, so most of the time is spent computing them in
>> > helper_compute_psr.
>>
>> I wonder if this can be optimized. I guess most RISC CPUs would have a
>> similar pro
Am 30.07.2015 um 10:55 schrieb Aurelien Jarno:
Note that when you say SPARC64 here, it's actually only the kernel, you
are using a 32-bit userland. And that makes a difference. Here are my
tests here:
installing NetBSD 6.5.1 SPARC64 seems to perform much better (compared
to Debian 7.8.0 SPARC6
Artyom Tarasenko writes:
> On Thu, Jul 30, 2015 at 9:12 AM, Paolo Bonzini wrote:
>>
>>
>> On 30/07/2015 05:47, Dennis Luehring wrote:
>>> so your aarch64 is just less todo for qemu - not EVERY >= 16bit memory
>>> access needs swapping or needs check for unaligned access to emulate
>>> bus-erros
On 31/07/15 16:43, Aurelien Jarno wrote:
> On 2015-07-31 17:31, Artyom Tarasenko wrote:
>> On Thu, Jul 30, 2015 at 5:50 PM, Aurelien Jarno wrote:
>>> On 2015-07-30 10:55, Aurelien Jarno wrote:
On 2015-07-30 10:16, Dennis Luehring wrote:
> Am 30.07.2015 um 09:52 schrieb Aurelien Jarno:
>>
On 2015-07-31 17:31, Artyom Tarasenko wrote:
> On Thu, Jul 30, 2015 at 5:50 PM, Aurelien Jarno wrote:
> > On 2015-07-30 10:55, Aurelien Jarno wrote:
> >> On 2015-07-30 10:16, Dennis Luehring wrote:
> >> > Am 30.07.2015 um 09:52 schrieb Aurelien Jarno:
> >> > >On 2015-07-30 05:52, Dennis Luehring w
On Thu, Jul 30, 2015 at 5:50 PM, Aurelien Jarno wrote:
> On 2015-07-30 10:55, Aurelien Jarno wrote:
>> On 2015-07-30 10:16, Dennis Luehring wrote:
>> > Am 30.07.2015 um 09:52 schrieb Aurelien Jarno:
>> > >On 2015-07-30 05:52, Dennis Luehring wrote:
>> > >> Am 29.07.2015 um 17:01 schrieb Aurelien J
Am 30.07.2015 um 12:09 schrieb Aurelien Jarno:
I am using Debian SPARC64 from debian-ports. But it's not really
ready-to-use and often broken.
the current 6.5.1 NetBSD is available for SPARC and SPARC64 - with SPARC
using 32bit Kernel/Userland and
SPARC64 with 64bit Kernel/Userland
and accor
On 2015-07-30 10:55, Aurelien Jarno wrote:
> On 2015-07-30 10:16, Dennis Luehring wrote:
> > Am 30.07.2015 um 09:52 schrieb Aurelien Jarno:
> > >On 2015-07-30 05:52, Dennis Luehring wrote:
> > >> Am 29.07.2015 um 17:01 schrieb Aurelien Jarno:
> > >> >The point is that emulation has a cost, and it's
On 2015-07-30 11:35, Artyom Tarasenko wrote:
> On Thu, Jul 30, 2015 at 10:55 AM, Aurelien Jarno wrote:
> > On 2015-07-30 10:16, Dennis Luehring wrote:
> >> Am 30.07.2015 um 09:52 schrieb Aurelien Jarno:
> >> >On 2015-07-30 05:52, Dennis Luehring wrote:
> >> >> Am 29.07.2015 um 17:01 schrieb Aureli
On Thu, Jul 30, 2015 at 10:55 AM, Aurelien Jarno wrote:
> On 2015-07-30 10:16, Dennis Luehring wrote:
>> Am 30.07.2015 um 09:52 schrieb Aurelien Jarno:
>> >On 2015-07-30 05:52, Dennis Luehring wrote:
>> >> Am 29.07.2015 um 17:01 schrieb Aurelien Jarno:
>> >> >The point is that emulation has a cost
On 2015-07-30 10:16, Dennis Luehring wrote:
> Am 30.07.2015 um 09:52 schrieb Aurelien Jarno:
> >On 2015-07-30 05:52, Dennis Luehring wrote:
> >> Am 29.07.2015 um 17:01 schrieb Aurelien Jarno:
> >> >The point is that emulation has a cost, and it's quite difficult to
> >> >to lower it and thus improv
On Thu, Jul 30, 2015 at 10:16 AM, Dennis Luehring wrote:
> Am 30.07.2015 um 09:52 schrieb Aurelien Jarno:
>>
>> On 2015-07-30 05:52, Dennis Luehring wrote:
>> > Am 29.07.2015 um 17:01 schrieb Aurelien Jarno:
>> > >The point is that emulation has a cost, and it's quite difficult to
>> > >to lower i
On Thu, Jul 30, 2015 at 9:12 AM, Paolo Bonzini wrote:
>
>
> On 30/07/2015 05:47, Dennis Luehring wrote:
>> so your aarch64 is just less todo for qemu - not EVERY >= 16bit memory
>> access needs swapping or needs check for unaligned access to emulate
>> bus-erros
>
> Not to mention register windows
Am 30.07.2015 um 09:52 schrieb Aurelien Jarno:
On 2015-07-30 05:52, Dennis Luehring wrote:
> Am 29.07.2015 um 17:01 schrieb Aurelien Jarno:
> >The point is that emulation has a cost, and it's quite difficult to
> >to lower it and thus improve the emulation speed.
>
> so its just not strange for y
On 2015-07-30 05:47, Dennis Luehring wrote:
> so your aarch64 is just less todo for qemu - not EVERY >= 16bit memory
> access needs swapping or needs check for unaligned access to emulate
> bus-erros
On recent Intel CPU, the byteswapping comes for free (MOVBE
instruction).
About the unaligned acc
On 2015-07-30 05:52, Dennis Luehring wrote:
> Am 29.07.2015 um 17:01 schrieb Aurelien Jarno:
> >The point is that emulation has a cost, and it's quite difficult to
> >to lower it and thus improve the emulation speed.
>
> so its just not strange for you to see an 1/100...200 of the native x64
> spe
On 30/07/2015 05:47, Dennis Luehring wrote:
> so your aarch64 is just less todo for qemu - not EVERY >= 16bit memory
> access needs swapping or needs check for unaligned access to emulate
> bus-erros
Not to mention register windows, which IIRC are the big source of pain
for SPARC.
Paolo
Am 29.07.2015 um 17:01 schrieb Aurelien Jarno:
The point is that emulation has a cost, and it's quite difficult to
to lower it and thus improve the emulation speed.
so its just not strange for you to see an 1/100...200 of the native x64
speed under qemu/SPARC64
i hoped that someone will jump u
so your aarch64 is just less todo for qemu - not EVERY >= 16bit memory
access needs swapping or needs check for unaligned access to emulate
bus-erros
Am 29.07.2015 um 16:41 schrieb Karel Gardas:
ubuntu@ubuntu:~$ ./a.out
endianess: little
try to access unaligned word
equal to 0x1234: YES
On 2015-07-29 15:45, Karel Gardas wrote:
> On Wed, Jul 29, 2015 at 12:20 PM, Dennis Luehring wrote:
> > Am 29.07.2015 um 11:17 schrieb Karel Gardas:
> >>
> >> If
> >> anybody is interested I can dig those old emails.
> >
> >
> > would be nice
>
> Here is speed comparison:
> https://lists.debian.o
On 2015-07-29 10:07, Dennis Luehring wrote:
> currently qemu emulates an TI UltraSparc IIi (Sabre)
> does that mean that qemu emulates the sparc somwhere around 270-480Mhz (i
> can't find the running mhz in qemu)
No, it emulates the TI UltraSparc IIi as fast as it can. It mostly
depends on your ho
On 2015-07-29 08:20, Dennis Luehring wrote:
> Am 28.07.2015 um 11:54 schrieb Artyom Tarasenko:
> >>>anything i can do to speedup the emulation?
> >Maybe try the fresh tcg optimizer improvements from Aurelien:
> >https://lists.gnu.org/archive/html/qemu-devel/2015-07/msg05133.html
>
> it don't seems
ubuntu@ubuntu:~$ ./a.out
endianess: little
try to access unaligned word
equal to 0x1234: YES
value: 0x1234
done
On Wed, Jul 29, 2015 at 3:55 PM, Dennis Luehring wrote:
> Am 29.07.2015 um 14:34 schrieb Karel Gardas:
>>
>> Once it boots, tell me how to find the asnwers to your
>> questions.
>
Am 29.07.2015 um 14:34 schrieb Karel Gardas:
Once it boots, tell me how to find the asnwers to your
questions.
compile with gcc test.cpp and run
---
#include
#include
#include
#include
#include
int main()
{
uint16_t value = 0x1234;
{
volatile uint8_t* ptr = (uint8_t*)&
On Wed, Jul 29, 2015 at 12:20 PM, Dennis Luehring wrote:
> Am 29.07.2015 um 11:17 schrieb Karel Gardas:
>>
>> If
>> anybody is interested I can dig those old emails.
>
>
> would be nice
Here is speed comparison:
https://lists.debian.org/debian-sparc/2015/02/msg1.html but whole
thread started
aarch64 booted, this is ubuntu 14.04.1 LTS, LSB:
ubuntu@ubuntu:~$ file /bin//bash
/bin//bash: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 3.7.0,
BuildID[sha1]=36b671892d00161eaeb9f602049f9ce830e9056e, stripped
ubuntu@ubuntu:~$ cat
On Wed, Jul 29, 2015 at 12:55 PM, Dennis Luehring wrote:
> Am 29.07.2015 um 11:17 schrieb Karel Gardas:
>>
>> What was interesting was that nbench2 was comparable on aarch64
>
>
> was aarch64 a little or big-endian system, with unaligned accesses possible?
This was Ubuntu with Linux kernel 3.13 s
On Tue, Jul 28, 2015 at 9:52 AM, Dennis Luehring wrote:
> (i've posted the question already on qemu-disc...@nongnu.org but was toled
> to better use this mailing list)
>
> i've prepared an Debian 7.8.0 image for SPARC64/qemu emulation for C/C++
> development before-real-hardware big-endian/unalign
Am 29.07.2015 um 11:17 schrieb Karel Gardas:
What was interesting was that nbench2 was comparable on aarch64
was aarch64 a little or big-endian system, with unaligned accesses possible?
Am 29.07.2015 um 11:17 schrieb Karel Gardas:
If
anybody is interested I can dig those old emails.
would be nice
On Wed, Jul 29, 2015 at 8:20 AM, Dennis Luehring wrote:
> Am 28.07.2015 um 11:54 schrieb Artyom Tarasenko:
>>>
>>> >anything i can do to speedup the emulation?
>>
>> Maybe try the fresh tcg optimizer improvements from Aurelien:
>> https://lists.gnu.org/archive/html/qemu-devel/2015-07/msg05133.html
currently qemu emulates an TI UltraSparc IIi (Sabre)
does that mean that qemu emulates the sparc somwhere around 270-480Mhz
(i can't find the running mhz in qemu)
how can i get the Mhz the sparc is running?
(cpuinfo and lscpu missing Mhz, dmidecode is not available,
/sys/devices/system/cpu/cpu
Am 28.07.2015 um 11:54 schrieb Artyom Tarasenko:
>anything i can do to speedup the emulation?
Maybe try the fresh tcg optimizer improvements from Aurelien:
https://lists.gnu.org/archive/html/qemu-devel/2015-07/msg05133.html
it don't seems to target sparc (or isn't ready) many x86/x64 only etc.
On Tue, Jul 28, 2015 at 9:52 AM, Dennis Luehring wrote:
> (i've posted the question already on qemu-disc...@nongnu.org but was toled
> to better use this mailing list)
>
> i've prepared an Debian 7.8.0 image for SPARC64/qemu emulation for C/C++
> development before-real-hardware big-endian/unalign
(i've posted the question already on qemu-disc...@nongnu.org but was
toled to better use this mailing list)
i've prepared an Debian 7.8.0 image for SPARC64/qemu emulation for C/C++
development before-real-hardware big-endian/unaligned tests
i've benchmarked compiling of single pugixml.cpp
(htt
78 matches
Mail list logo
