If the old Sparc graphics group is no more, how would this affect the
development of graphics software/hardware for UltraSparc workstations? There
must be some people that still buy Blade and the new Ultra 45 workstations. Or
maybe those workstations are mainly used for specific applications, li
Is anyone working on the Render extension? I understand that Solaris is more of
a server OS and that almost every Sun employee owns a Mac, but making Solaris
more desktop friendly would certainly be a goog thing.
I only wish NetBSD sparc64 was as stable as Solaris and had decent SMP support
:-)
Hi, I have Ultra 10 workstation 440MHz USIIi with creator3d framebuffer. Some
GTK applications seem to render quite slow. I run remote X sessions to a quad
CPU E450 machine. When Xserver is running on Pentium3 - NetBSD, everything is
rendered pretty fast. When Xserver is running on Ultra 10 - Op
I thought an OS kernel was supposed to synchronise hardware counters on
multiple CPUs when it was loading??
In regard to %tick being privileged register: yes and no. There is flag in that
register the kernel can set, to allow user processes access to it. Earlier
versions of Solaris made it priv
I don't think it's filesystem related, i.e. there is not much I/O happening at
the time. Maybe NetBSD's /bin/sh is a lot faster than Solaris
/bin/{sh,ksh,bash}, maybe NetBSD's fork() is a lot faster. I didn't benchmark
the two operating systems. I'm hoping to conduct some benchmarks soon and wil
I've given up, this benchmark needs more thought and testing. Some tests just
get stuck in infinite loops
Running: mallocT2_1k
10 hours later, it's still running... and that is on 440MHz Sparc machine,
running Solaris 10.
Restarted the benchmark again, and that test completed in 0.03 s
OK, thanks for the patch, it fixed compilation errors.
Just to let you know, there is a bug in some of the benchmarks - longjmp.c and
siglongjmp.c
int
benchmark(void *tsd, result_t *res)
{
int i = 0;
jmp_buf env;
(void) setjmp(env);
ce to `pthread_mutexattr_setpshared'
cascade_mutex.o(.text+0x1fc): In function `benchmark_initrun':
: undefined reference to `pthread_mutexattr_setpshared'
gmake[1]: *** [cascade_mutex] Error 1
rm bind.o cascade_mutex.o
gmake[1]: Leaving directory `/opt/home/roman/libMicro-0.3.0/bin-sparc64&
I use both official Solaris 10 and Nevada build 28.
I don't even have to measure time, you can tell forks are slow just by looking
at it. Like I said I build software from pkgsrc, many packages have GNU
configure scripts that fork and execute small test programs. On Solaris those
scripts run pai
I'm not running any benchmarks, I just observe that Solaris feels slower than
NetBSD on the same hardware. Everybody keeps saying that fork() on Solaris is
very slow and I can definitely see that when compiling applications from
pkgsrc. Is there no way to speed it up?
This message posted from op
Hi, I run both Solaris 10 and NetBSD-current on Ultra 10. What I notice is that
NetBSD performs much faster and Solaris feels quite bloated. Forking new
processes on Solaris is so slow, why is that? Some applications consume a lot
more CPU time on Solaris, compared to the same applications on Ne
11 matches
Mail list logo
