Russ Allbery wrote:
[... explanation of the tradeoffs snipped ...]
> Note, btw, that for some algorithms, you might gain significant speed,
> more than the PIC difference, by being able to compile for more capable
> processors (enabling SSE2 can make a huge difference, for instance).
> Shared libr
Roger Leigh (23/02/2010):
> 1) sbuild no longer defaults the distribution to "unstable", and
> requires setting by hand with --distribution unless configured in
> .sbuildrc. This is to prevent accidental uploads to the wrong
> distribution.
Yay. :D
> 2) sbuild now lists all p
Jonathan Nieder writes:
> Russ Allbery wrote:
>> That being said, a 5% performance gain from using statically linked
>> non-PIC code doesn't strike me as very compelling even for older systems.
> Thank you for your candor; even a hunch like this one is the sort of thing
> I was interested to hea
Hi,
I've released sbuild version 0.60.0, which has been uploaded to
unstable and is also available from
git://git.debian.org/git/buildd-tools/sbuild
(tag release/sbuild-0.60.0).
Quite a number of people contributed to this release, and their
individual contributions are in the shortlog, below.
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Owner: Tzafrir Cohen
* Package Name: asterisk-moh-opsound
Version : 2.03
Upstream Author : Digium Inc.
* URL : http://downloads.asterisk.org/pub/telephony/sounds
* License : CC-BY-SA-3
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Owner: Tzafrir Cohen
* Package Name: asterisk-extra-sounds
Version : 1.4.10
Upstream Author : Digium Inc.
* URL : http://downloads.asterisk.org/pub/telephony/sounds
* License : [*]
* P
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Owner: Tzafrir Cohen
* Package Name: asterisk-core-sounds
Version : 1.4.17
Upstream Author : Digium Inc.
* URL : http://downloads.asterisk.org/pub/telephony/sounds
* License : CC-BY-SA
Hi Russ,
Russ Allbery wrote:
> That being said, a 5% performance gain from using statically linked
> non-PIC code doesn't strike me as very compelling even for older systems.
Thank you for your candor; even a hunch like this one is the sort of thing
I was interested to hear.
I got the 6-7% diff
Thomas Weber wrote:
> Right, and following Wikipedia, they are clocked at 2GHz at most. I have
> some problem understanding someone who buys such a system and at the
> same time cares about 5% speed difference.
If my netbook takes 5% longer, then yes, I do care because that means it
has run at a b
Josselin Mouette wrote:
> Le mardi 23 février 2010 à 20:32 +0100, Marco d'Itri a écrit :
>> Anyway, there are often good reasons to use x86 on modern hardware
>> (think about laptops and smaller VPSes).
>
> You mean, like saving memory?
>
> Wait… wouldn’t you save more memory by using shared lib
Thomas Weber writes:
> And sorry, you don't care about speed if you still run *that* old
> hardware, otherwise you would have upgraded. (I bought my current
> desktop used and it is already able to run amd64).
Surely this is exactly opposite: speed matters much more on older hardware
that runs s
On Tue, Feb 23, 2010 at 04:45:22PM -0500, Joey Hess wrote:
> Thomas Weber wrote:
> > You have x86 hardware that is so old that it doesn't run amd64, but at
> > the same moment you care about speed?
>
> It's not particularly hard to find new hardware with 32 bit Atom chips
> in it. There's this who
On Tue, Feb 23, 2010 at 08:32:09PM +0100, Marco d'Itri wrote:
> On Feb 23, Thomas Weber wrote:
>
> > You have x86 hardware that is so old that it doesn't run amd64, but at
> > the same moment you care about speed?
> Why should I not care about speed if the hardware is slow?
That you care persona
Thomas Weber wrote:
> You have x86 hardware that is so old that it doesn't run amd64, but at
> the same moment you care about speed?
It's not particularly hard to find new hardware with 32 bit Atom chips
in it. There's this whole "netbook" thing..
--
see shy jo
signature.asc
Description: Digit
Marco d'Itri wrote:
> If the programs are linked statically then they will have the same
> memory footprint of programs linked with non-PIC libraries, so the
> situation will not be worse in this sense.
On non-i386 architectures, I will turn on --enable-dynamic to link to
the current PIC library.
Hi!
On Tue, 2010-02-23 at 17:14:00 +1100, Robert Collins wrote:
> On Tue, 2010-02-23 at 05:20 +0100, Guillem Jover wrote:
> > I don't think this would be worth it, as Marco has also said, if the
> > system is hosed but you can still get to the point of obtaining a
> > package to install you might
Package: wnpp
Severity: wishlist
Owner: Matthijs Kooijman
* Package name: openttd-opensfx
Version : 0.2.1
Upstream Author : Various
* URL : http://dev.openttdcoop.org/projects/opengfx
* License : Creative Commons Sampling Plus
Description : a free sound s
Le mardi 23 février 2010 à 20:32 +0100, Marco d'Itri a écrit :
> Anyway, there are often good reasons to use x86 on modern hardware
> (think about laptops and smaller VPSes).
You mean, like saving memory?
Wait… wouldn’t you save more memory by using shared libraries and PIC
code?
--
.''`.
On Feb 23, Jonathan Nieder wrote:
> In this case the speed difference from using non-PIC code is
> noticeable. But the memory pressure from not sharing code between
> processes might mean it is not worth it --- I am really torn.
If the programs are linked statically then they will have the same
On Tue, Feb 23, 2010 at 2:35 AM, Fuentes, Adolfo
wrote:
> Hello Raju.
>
> is a link in "/etc/alternatives" to "/usr/bin/gfortran".
Ok, thanks.
>
> When typing "gfortran -v" the options are:
>
> ]$ gfortran -v
> Using built-in specs.
> Target: i486-linux-gnu
> Configured with: ../src/configure
On Feb 23, Thomas Weber wrote:
> You have x86 hardware that is so old that it doesn't run amd64, but at
> the same moment you care about speed?
Why should I not care about speed if the hardware is slow?
Anyway, there are often good reasons to use x86 on modern hardware
(think about laptops and sm
Thomas Weber wrote:
>>> Le mardi 23 février 2010 à 14:43 +0100, Marco d'Itri a écrit :
Using non-PIC code for a 5% speed up looks like an acceptable trade off
to me, but it really must be restricted only to architectures which
need it.
[...]
> You have x86 hardware that is so old th
On Tue, Feb 23, 2010 at 04:01:51PM +0100, Marco d'Itri wrote:
> On Feb 23, Josselin Mouette wrote:
>
> > Le mardi 23 février 2010 à 14:43 +0100, Marco d'Itri a écrit :
> > > Using non-PIC code for a 5% speed up looks like an acceptable trade off
> > > to me, but it really must be restricted only
Package: wnpp
Severity: wishlist
Owner: "d.haley"
* Package name: liblemon1
Version : 1.1.1
Upstream Author : Egervary Research Group on Combinatorial Optimization
(EGRES)
* URL : http://lemon.cs.elte.hu/
* License : Boost 1.0
Programming Lang: C++
Descr
On Feb 23, Josselin Mouette wrote:
> Le mardi 23 février 2010 à 14:43 +0100, Marco d'Itri a écrit :
> > Using non-PIC code for a 5% speed up looks like an acceptable trade off
> > to me, but it really must be restricted only to architectures which
> > need it.
> Those who worry about a 5% speedu
Jaunā izsoles veikala atklāšana jau 18. februārī! Reģistrējies
www.ebid.lv un saņem dāvanā divas likmes bez maksas! Iepazīsties ar izsoles
precēm jau tagad un izmēģini veiksmi – varbūt esi vienīgais solītājs! Ja
izsoles laikā neatrodies pie datora, lieliska iespēja
Le mardi 23 février 2010 à 14:43 +0100, Marco d'Itri a écrit :
> Using non-PIC code for a 5% speed up looks like an acceptable trade off
> to me, but it really must be restricted only to architectures which
> need it.
Those who worry about a 5% speedup should use amd64. Which is an
architecture t
On Feb 23, Jonathan Nieder wrote:
> The usual i386-centric reason: the PIC version is (~5%) slower than
> the non-PIC version. See PACKAGERS in the source, section 4.1.
> I considered doing this only on i386, but since I only have an i386 to
> test on, I would worry about missing packaging bugs.
Package: www.debian.org
Tags: security
Severity: wishlist
X-debbugs-cc: debian-...@lists.debian.org,debian-devel@lists.debian.org,
rho...@deb.at
> "GF" == Gerfried Fuchs writes:
GF> Hi!
GF> * [2010-02-22 18:12:46 CET]:
>> Do mention secur...@debian.org on http://www.debian.org/security
29 matches
Mail list logo
