Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
21.12.2011, 04:28, O. Hartmann ohart...@zedat.fu-berlin.de: On 12/21/11 00:29, Jeremy Chadwick wrote: On Tue, Dec 20, 2011 at 11:54:23PM +0100, O. Hartmann wrote: On 12/20/11 22:45, Samuel J. Greear wrote: http://www.osnews.com/story/25334/DragonFly_BSD_MP_Performance_Significantly_Improved PostgreSQL tests, see the linked PDF for #'s on FreeBSD, DragonFly, Linux and Solaris. Steps to reproduce these benchmarks provided. Sam On Tue, Dec 20, 2011 at 1:20 PM, Igor Mozolevsky i...@hybrid-lab.co.ukwrote: Interestingly, while people seem to be (arguably rightly) focused on criticising Phoronix's benchmarking, nobody has offered an alternative benchmark; and while (again, arguably rightly) it is important to benchmark real world performance, equally, nobody has offered any numbers in relation to, for example, HTTP or SMTP, or any other real world-application torture tests done on the aforementioned two platforms... IMO, this just goes to show that doing is hard and criticising is much easier (yes, I am aware of the irony involved in making this statement, but someone has to!) Cheers, Igor M :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Thanks for those numbers. Impressive how Matthew Dillon's project jumps forward now. And it is still impressive to see that the picture is still in the right place when it comes to a comparison to Linux. Also, OpenIndiana shows an impressive performance. Preface to my long post below: The things being discussed here are benchmarks, as in how much work can you get out of Thing. This is VERY DIFFERENT from testing interactivity in a scheduler, which is more of a test that says when Thing X is executed while heavier-Thing Y is also being executed, how much interaction is lost in Thing X. The reason people notice this when using Xorg is because it's visual, in an environment where responsiveness is absolutely mandatory above all else. Nobody is going to put up with a system where during a buildworld they go to move a window or click a mouse button or type a key and find that the window doesn't move, the mouse click is lost, or the key typed has gone into the bit bucket -- or, that those things are SEVERELY delayed, to the point where interactivity is crap. I whitnessed sticky, jumpy and non-responsive-for seconds FreeBSD servers (serving homes, NFS/SAMBA and PostgreSQL database (small)). Those seconds where enough to cut a ssh line. Not funny. Network traffic droped significantly. X/Desktop makes the problem visible, indeed. But not seeing it does not mean it isn't there. This might be the reason why FreeBSD is so much behind when it comes to X? Well... Are you talking about FreeBSD being laggy with the X and other GUI staff? Well, am I so lucky to have great responsiveness and interactivity here in X with the FreeBSD? The interactiveness was one the reasons I've switched my desktop from Windows to *nix (specifically FreeBSD). I just want to make that clear to folks. This immense thread has been Regards, Vans. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
FreeBSD-9.0-BETA1-i386-bootonly
Hi. Tried to use FreeBSD-9.0-BETA1-i386-bootonly.iso in VirtualBox to test. Installation stops after trying to fetch files from ftp. Attached screenshot is informative, I think. Seems to use i386/ twice for some reason. Regards, Vans.___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0-CURRENT r220692 cc1: internal compiler error: Segmentation fault: 11
Hello.
Don't know is this related.
I've got rather fresh 9.0-CURRENT (checked out few days ago) built with clang.
And I use clang as the system compiler, but ruby fails to build with clang. So
I've tried gcc. But with gcc I've got this:
..
configure:3211: checking whether the C compiler works
configure:3233: cc -I/usr/include -O2 -pipe -march=native -fno-strict-aliasing
-I/usr/include -rpath=/usr/lib:/usr/local/lib -pthread conft
est.c -L/usr/lib -rpath=/usr/lib:/usr/local/lib -pthread 5
Segmentation fault (core dumped)
configure:3237: $? = 139
configure:3275: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME
| #define PACKAGE_TARNAME
| #define PACKAGE_VERSION
| #define PACKAGE_STRING
| #define PACKAGE_BUGREPORT
| #define PACKAGE_URL
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3280: error: in
`/mnt/portworkdir/usr/ports/lang/ruby18/work/ruby-1.8.7-p302':
configure:3283: error: C compiler cannot create executables
..
As far as I remeber, all was ok when I had base gcc build by gcc not clang. But
this could be unrelated.
Regards.
26.04.2011, 12:04, Matthias Apitz g...@unixarea.de:
Hello,
I'm trying to compile /usr/ports/mail/evolution-exchange/ and the gcc
crashes with:
[root@vm-9Current /usr/ports/mail/evolution-exchange]# LANG=C make
=== Building for evolution-exchange-2.32.1_1
gmake all-recursive
gmake[1]: Entering directory
`/usr/ports/mail/evolution-exchange/work/evolution-exchange-2.32.1'
Making all in server
gmake[2]: Entering directory
`/usr/ports/mail/evolution-exchange/work/evolution-exchange-2.32.1/server'
Making all in xntlm
gmake[3]: Entering directory
`/usr/ports/mail/evolution-exchange/work/evolution-exchange-2.32.1/server/xntlm'
CC libxntlm_la-xntlm.lo
cc1: internal compiler error: Segmentation fault: 11
Some notes about this:
- the system runs in a VMworkstation 7.x
- it has already compliled kernel, userland and ~1000 ports without any
crash, i.e. it is *not* the typical hardware related crash;
- the above mentioned version evolution-exchange-2.32.1_1 is a fake, in
real it is compiling the original evolution-exchange-2.32.3 sources;
- it is fully reproduceable
What next?
(David, should it be posted to evolut...@gnome.org as well?)
matthias
--
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e g...@unixarea.de; - w http://www.unixarea.de/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
