Re: i386 compatibility libstdc++
Arnd Bergmann [EMAIL PROTECTED] writes: It would surely be nice to see performance numbers from actual applications. After all, the applications are normally doing some things besides low level atomic operations. Indeed, it would be interesting to find out how often applications invoke these operations. Notice, however, that primitive operations like std::string manipulation use these functions, so they *are* used quite often. Nevertheless, I think it would be best to also start a full Debian/i686 port which will be 100% compatible with Debian on i386 except that it only runs on PentiumPro compatible machines, i.e. Pentium 2/3/4/M, Xeon, Celeron, Athlon, Duron and Opteron but not Pentium, K5, K6 and most VIA/cyrix chips. I think it would be best to start a port that stops supporting i386, period, both for performance and compatibility reasons. Regards, Martin
Re: i386 compatibility libstdc++
On Sun, Apr 27, 2003 at 12:52:11PM -0400, Anthony DeRobertis wrote: On Sat, 2003-04-26 at 03:56, Chris Cheney wrote: I also find it hard to believe that the majority of our users do not have or can not purchase a system that is less than 7 years old. I have a brand new 486-class system with 32MB of RAM. It's less than 6 months old. Please explain how I can get a similar system, running on a similar amount of power, and with no moving parts (i.e., no fans) using, even a P-II. Mi Micro ATX pegasos motherboard with 600MHz G3 CPU is fanless, sure the 750Cxe should consume around 3-5 W or something such, but i hear the 750Fx used in the ibooks consumes even less. Friendly, Sven Luther
Re: i386 compatibility libstdc++
* Anthony DeRobertis | On Sat, 2003-04-26 at 03:56, Chris Cheney wrote: | | I also find it hard to believe that the majority of our users do not | have or can not purchase a system that is less than 7 years old. | | I have a brand new 486-class system with 32MB of RAM. It's less than 6 | months old. | | Please explain how I can get a similar system, running on a similar | amount of power, and with no moving parts (i.e., no fans) using, even a | P-II. http://www.pipegroup.com/nano/docs/p266.html (at prototype stage, but «soon available») Or you could use a celeron 500 or something which you could just cool using a rib (or an athlon 550 or similar). -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: i386 compatibility libstdc++
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 30 April 2003 16:29, Tollef Fog Heen wrote: * Anthony DeRobertis | Please explain how I can get a similar system, running on a similar | amount of power, and with no moving parts (i.e., no fans) using, even a | P-II. http://www.pipegroup.com/nano/docs/p266.html (at prototype stage, but «soon available») The most common one available today is the VIA APIA system: http://www.viavpsd.com/product/epia_mini_itx_spec.jsp?motherboardId=21 http://search.ebay.com/search/search.dll?MfcISAPICommand=GetResultquery=epia Arnd -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+r/Hu5t5GS2LDRf4RAprnAJ44cqKpvy1eRIcaMNQrxm29mkbLlQCfTvg9 6ODFY2g6gjTaNBcBPpwzlxs= =9mNT -END PGP SIGNATURE-
Re: i386 compatibility libstdc++
Arnd Bergmann [EMAIL PROTECTED] writes:
No, look at my patch again. If you build without i486 optimization,
the compiler will see only the extern declaration for
__exchange_and_add().
I see. What sonames do you suggest to give to the two copies of
libstdc++? You once said you'd call them libstdc++-i386.so.5,
but that you would also provide them under the name libstdc++.so.5.
This solution seems to have the following properties:
1. It becomes possible to mix native Debian and foreign binaries
on i486 (provided the dynamic linker can really find the right
library all the time)
2. Running Debian binaries on foreign systems won't be easy.
In particular, they all link to libstdc++-i386.so.5, so
such a library needs to be provided for other systems.
Mixing that library with that native libstdc++.so.5 might
cause problems, so anybody running a Debian binary on
a foreign system would need the binary and all shared libraries
it links with, even though those libraries have the same
sonames as the libraries available on the foreign system.
3. Debian i486 binaries take a significant performance hit.
The attached program demonstrates that the cost of
__atomic_add is roughly twice as much if done out-of-line,
compared to the inline version. On my system, I get
inline: 2.4061
out-of-line: 4.60658
Regards,
Martin
#include sys/time.h
#include stdio.h
typedef int _Atomic_word;
const int nrepeats = 1;
static inline void
atomic_add (volatile _Atomic_word* __mem, int __val)
{
__asm__ __volatile__ (lock; addl %0,%1
: : ir (__val), m (*__mem) : memory);
}
static void
atomic_add2 (volatile _Atomic_word* __mem, int __val);
int main()
{
struct timeval start, stop;
double total;
int i;
_Atomic_word w = 0;
// inline
gettimeofday(start, 0);
for (i = 0; i nrepeats; i++)
atomic_add(w, 1);
gettimeofday(stop, 0);
total = stop.tv_sec + 1e-6*stop.tv_usec -
(start.tv_sec + 1e-6*start.tv_usec);
printf(inline: %g\n, total);
// out-of-line
gettimeofday(start, 0);
for (i = 0; i nrepeats; i++)
atomic_add2(w, 1);
gettimeofday(stop, 0);
total = stop.tv_sec + 1e-6*stop.tv_usec -
(start.tv_sec + 1e-6*start.tv_usec);
printf(out-of-line: %g\n, total);
}
static void
atomic_add2 (volatile _Atomic_word* __mem, int __val)
{
__asm__ __volatile__ (lock; addl %0,%1
: : ir (__val), m (*__mem) : memory);
}
Re: i386 compatibility libstdc++
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 29 April 2003 07:50, you wrote: Arnd Bergmann [EMAIL PROTECTED] writes: No, look at my patch again. If you build without i486 optimization, the compiler will see only the extern declaration for __exchange_and_add(). I see. What sonames do you suggest to give to the two copies of libstdc++? You once said you'd call them libstdc++-i386.so.5, Yes, either have libstdc++-i386 for i386 optimized binaries plus libstdc++ for others or have libstdc++ everywhere. Both should work in principle. Using libstdc++-i386 will break Debian binaries on other platforms explicitly, which may or may not be considered a good idea. 2. Running Debian binaries on foreign systems won't be easy. In particular, they all link to libstdc++-i386.so.5, so such a library needs to be provided for other systems. Mixing that library with that native libstdc++.so.5 might cause problems, so anybody running a Debian binary on a foreign system would need the binary and all shared libraries it links with, even though those libraries have the same sonames as the libraries available on the foreign system. There are two ways out of this: a) The patch gets merged upstream. It won't hurt anyone who is building i486+ optimized binaries and fixes a real bug. This would mean we should not have libstdc++-i386.so.5. b) We provide a libstdc++-i386.so.$(version) file that contains only the __exchange_and_add function and is linked to libstdc++.so. 3. Debian i486 binaries take a significant performance hit. The attached program demonstrates that the cost of __atomic_add is roughly twice as much if done out-of-line, compared to the inline version. On my system, I get inline: 2.4061 out-of-line: 4.60658 We can shave a bit off by making the function __attribute__((regparm(2))) and perhaps by using a trivial non-locking variant when compiling without threads, as the i386 version uses the mutex only in those cases and AFAICS it is compatible with the i486 version otherwise. The numbers I get on my P3 now are (in average cpu cycles): non-locked locked i486 inline: 6.524.2 i486 out-of-line: 7.335.8 i386 inline: 4.5 189.9 i386 out-of-line: 9.9 196.4 If we know at compile time that locking (neither 'lock;' prefix nor the mutex call) is never needed, we can even get much faster than the current i486 code. Also, if an application or library cares about this sort of micro-optimization, it probably should be provided in an optimized version anyway. Arnd -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+rnlj5t5GS2LDRf4RAm1SAJ0WwDALgWCpJ6/8l+xfk5oSWeftuwCeOoKz jsbSsLCw1g4NlK6axPBQwXk= =iwhP -END PGP SIGNATURE-
Re: i386 compatibility libstdc++
Arnd Bergmann [EMAIL PROTECTED] writes: a) The patch gets merged upstream. It won't hurt anyone who is building i486+ optimized binaries and fixes a real bug. Upstream won't accept the patch, because of the performance penalty. Even if upstream accepts the patch, that won't be before gcc 3.4. However, the gcc 3.2/3.3 ABI will stay with us for a long time (most likely until after the next Debian release). b) We provide a libstdc++-i386.so.$(version) file that contains only the __exchange_and_add function and is linked to libstdc++.so. That would work, yes. We can shave a bit off by making the function __attribute__((regparm(2))) Even with that change, and -fomit-frame-pointer, I get inline: 2.39809 out-of-line: 4.0224 i.e. this is still a 60% slowdown (in a test case where the processor does branch prediction correctly all the time, and everything is in the cache). The assembler code is _Z11atomic_add2PVii: lock; addl %edx,(%eax) ret so it can't get any better. The performance hit is still unacceptable. and perhaps by using a trivial non-locking variant when compiling without threads, as the i386 version uses the mutex only in those cases and AFAICS it is compatible with the i486 version otherwise. That won't help anything. Compiling without threads isn't really supported on Linux: if threads are not used, this is always a link-time/runtime issue, not a compile time issue. If we know at compile time that locking (neither 'lock;' prefix nor the mutex call) is never needed, we can even get much faster than the current i486 code. We never know that. Also, if an application or library cares about this sort of micro-optimization, it probably should be provided in an optimized version anyway. I think the performance loss for applications like KDE will be significant. I doubt that providing two versions of KDE (i386 and i486+) would be feasible. Regards, Martin
Re: i386 compatibility libstdc++
This one time, at band camp, [EMAIL PROTECTED] (Martin v. L) wrote: I think the performance loss for applications like KDE will be significant. I doubt that providing two versions of KDE (i386 and i486+) would be feasible. Not starting a flamewar here, but in all honesty, who is going to try to use KDE on a 386 anyway? Actually, while we are on that, who is even going to try to use X at all on a 386? -- You said homosexuals form a small percentage of the population. So do Jews. Is that a reason to deny someone equality? - Richard Marceau
Re: i386 compatibility libstdc++
Morgon Kanter wrote: Not starting a flamewar here, but in all honesty, who is going to try to use KDE on a 386 anyway? Actually, while we are on that, who is even going to try to use X at all on a 386? Probably nobody will. IMO, it is the worse that the KDE binaries have to be built for i386 compatibility (as the Debian package will have i386 in its name) Regards, Martin
Re: i386 compatibility libstdc++
Morgon Kanter [EMAIL PROTECTED] wrote: This one time, at band camp, [EMAIL PROTECTED] (Martin v. L) wrote: I think the performance loss for applications like KDE will be significant. I doubt that providing two versions of KDE (i386 and i486+) would be feasible. Not starting a flamewar here, but in all honesty, who is going to try to use KDE on a 386 anyway? Actually, while we are on that, who is even going to try to use X at all on a 386? Afaict the performance hit Martin is talking about does not hit i386 but i486+ [EMAIL PROTECTED] cu andreas
Re: i386 compatibility libstdc++
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 29 April 2003 21:22, Martin v. Löwis wrote: That won't help anything. Compiling without threads isn't really supported on Linux: if threads are not used, this is always a link-time/runtime issue, not a compile time issue. Right, forget what I said about that. Also, if an application or library cares about this sort of micro-optimization, it probably should be provided in an optimized version anyway. I think the performance loss for applications like KDE will be significant. I doubt that providing two versions of KDE (i386 and i486+) would be feasible. It would surely be nice to see performance numbers from actual applications. After all, the applications are normally doing some things besides low level atomic operations. When the i386 and the i486 libraries are compatible, we can decide what to do with each package case-by-case with these options: 1. not performance critical but important (e.g. apt) 2. won't work on i386 anyway and therefore can be built for i486 (e.g. mozilla or kde) 3. might be used on i386 but is performance critical and should be provided for i386 as well as i[56]86 (e.g. libqt3) Since category 3. will be very small (I could not come up with any example besides libqt3 and even that is debatable), this should solve the problem. Nevertheless, I think it would be best to also start a full Debian/i686 port which will be 100% compatible with Debian on i386 except that it only runs on PentiumPro compatible machines, i.e. Pentium 2/3/4/M, Xeon, Celeron, Athlon, Duron and Opteron but not Pentium, K5, K6 and most VIA/cyrix chips. Arnd -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+rvna5t5GS2LDRf4RAirIAJ9ei78r+TXOzdQlQfL4dk5MoWmoTACfZ+Yh a1SZdcTVT273JvuzYi7LQS8= =TIk2 -END PGP SIGNATURE-
Re: i386 compatibility libstdc++
Guido Guenther wrote: On Sat, Apr 26, 2003 at 09:05:50PM -0500, Gunnar Wolf wrote: I agree, the vast majority of our users can afford newer machines. So, I think we should drop m68k, mips and other similar unfashionable old archs, don't you think? The majority of our users will be happy... I'm not sure where the misconception of mips being an old arch comes from. Just look at the au1500 or the R1x000 CPUs. What are criteria for an architecture being old and unfashionable? Being unknown by the writer? There are still people out there who believe that x86 is the only (true) architecture. *sigh* It's just the cheapest crap one can get, and it's only cheap because of it's quantity and marketing (read windoze), not because of its quality. Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law
Re: i386 compatibility libstdc++
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Saturday 26 April 2003 16:38, Matthew Garrett wrote:
Is it possible to fix this (ie, provide ABI compatible versions for
i386 and i486) without breaking stuff? 386s are faster than many other
pieces of hardware that we still support, so dropping them seems strange
- on the other hand, an i386 sub-distribution sounds like a world of
pain. Having a standard library that only supports one of the allegedly
supported processors if the ABI changes sounds like the real bug to me.
Right. Any reason why the patch below should not work? When
__exchange_and_add is an extern function, the implementation does not
matter to applications using it. Binaries optimized for i486 or higher
can still use the inline function then, just i386 optimized ones will
be even slower than they are now. There will of course have to be two
variants of libstdc++ -- binaries built for i486 will require the new
library but all other c++ libraries and application are compatible
regardless of their optimization level.
We should still discuss an i686 (or i586) optimized port, but fixing
the problem will make it possible to seperate the issues.
Arnd
- --- config/cpu/i486/atomicity.h 2002-06-24 07:47:41.0 +0200
+++ config/cpu/i486/atomicity.h.fixed 2003-04-28 11:27:31.0 +0200
@@ -32,6 +32,10 @@
typedef int _Atomic_word;
+
+#if defined(__i486) || defined(__i586) || defined(__i686) || defined(__k6) ||
defined(__athlon) || defined(__pentium4) || defined(__x86_64)
+// the i486 and above part
+
static inline _Atomic_word
__attribute__ ((__unused__))
__exchange_and_add (volatile _Atomic_word *__mem, int __val)
@@ -52,6 +56,21 @@
: : ir (__val), m (*__mem) : memory);
}
+#else /* i386 compatible */
+
+extern _Atomic_word
+__attribute__ ((__unused__))
+__exchange_and_add (volatile _Atomic_word* __mem, int __val);
+
+static inline void
+__attribute__ ((__unused__))
+__atomic_add (volatile _Atomic_word* __mem, int __val)
+{
+ (void) __exchange_and_add (__mem, __val);
+}
+
+#endif
+
#endif /* atomicity.h */
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+rPYr5t5GS2LDRf4RAo3lAKCZOQw1R+q+kKOmHOg+nFeHvVtxbgCdFDlR
qCRF90VJyxslt+PnTSBP0J4=
=fWdT
-END PGP SIGNATURE-
Re: i386 compatibility libstdc++
Arnd Bergmann [EMAIL PROTECTED] writes: Right. Any reason why the patch below should not work? Yes, plenty. When __exchange_and_add is an extern function, the implementation does not matter to applications using it. Binaries optimized for i486 or higher can still use the inline function then, just i386 optimized ones will be even slower than they are now. There will of course have to be two variants of libstdc++ -- binaries built for i486 will require the new library but all other c++ libraries and application are compatible regardless of their optimization level. So should the standard binaries (apt, groff, OpenGL libraries, kde libraries) be compiled for 386 or 486? If 486, how can you run the packages on 386? If 386, how will they be compatible with other distributions? More importantly, how will binaries created for other distribution work on Debian? If you have a library compiled for 386 and a foreign binary compiled for 486, you may experience data corruption: the 386 code will modify atomic values one way, and the 486 code *in the same process* will modify them another way. This just cannot work. We should still discuss an i686 (or i586) optimized port, but fixing the problem will make it possible to seperate the issues. I can see no fix for the problem in this patch. Regards, Martin
Re: i386 compatibility libstdc++
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 28 April 2003 22:00, Martin v. Löwis wrote: Arnd Bergmann [EMAIL PROTECTED] writes: So should the standard binaries (apt, groff, OpenGL libraries, kde libraries) be compiled for 386 or 486? If 486, how can you run the packages on 386? They have to be compiled for i386, as they have always been. If they were compiled for i486, they would not run on i386 anyway, with or without the bug. We can optionally provide optimized binaries that don't run on i386, but that question is unrelated and we can freely mix them as long as the i486 libstdc++ is used. If 386, how will they be compatible with other distributions? More Only one way. You can use alien packages on Debian, but not Debian C++ packages on other distributions. Is there a reason to care about this? importantly, how will binaries created for other distribution work on Debian? If you have a library compiled for 386 and a foreign binary compiled for 486, you may experience data corruption: the 386 code will modify atomic values one way, and the 486 code *in the same process* will modify them another way. This just cannot work. Ok, I probably wasn't clear enough about the actual trick. If you want to use foreign binaries or build any debian packages libraries with C++ for i486+, you need to install the i486 libstdc++ files. For example, we could have these files in libstdc++5_3.3-x_i386.deb: /usr/lib/i386/libstdc++-i386.so.5 - libstdc++.so.5.0.3 /usr/lib/i386/libstdc++.so.5.0.3 /usr/lib/i486/libstdc++.so.5 - libstdc++.so.5.0.3 /usr/lib/i486/libstdc++-i386.so.5 - libstdc++.so.5.0.3 /usr/lib/i486/libstdc++.so.5.0.3 Obviously, the /usr/lib/i386/ variant is optimized for i386 and uses the old implementation, while the one in /usr/lib/i486 uses the new atomicity variant internally. Both provide an __exchange_and_add() extern function with their respective implementation. All default packages are built for i386 (as always) and linked for with the soname libstdc++-i386.so.5. On i486+ systems, the runtime linker will automatically use /usr/lib/i486/libstdc++-i386.so.5, which resolve the __exchange_and_add() function to the trivial assembly version. Binaries built for i486 will use the inline __exchange_and_add() function. Like alien binaries, they must not be run with the i386 library, so they use another soname (libstdc++.so.5). On i386 systems, those won't work, and the runtime linker will reject them as well. Arnd -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+rZPr5t5GS2LDRf4RAinOAJ9vha7+mu0ECjOuoBscrrm1tUtx7gCfdfB3 oY8oeWDtrxC2cBlXKvBiFzw= =s1A0 -END PGP SIGNATURE-
Re: i386 compatibility libstdc++
Arnd Bergmann [EMAIL PROTECTED] writes: They have to be compiled for i386, as they have always been. If they were compiled for i486, they would not run on i386 anyway, with or without the bug. But if they are compiled for i386, they won't run on other Linux systems, thus losing binary compatibility. Ok, I probably wasn't clear enough about the actual trick. If you want to use foreign binaries or build any debian packages libraries with C++ for i486+, you need to install the i486 libstdc++ files. Not only those, but also all other libraries that the executable links with. For example, we could have these files in libstdc++5_3.3-x_i386.deb: /usr/lib/i386/libstdc++-i386.so.5 - libstdc++.so.5.0.3 /usr/lib/i386/libstdc++.so.5.0.3 /usr/lib/i486/libstdc++.so.5 - libstdc++.so.5.0.3 /usr/lib/i486/libstdc++-i386.so.5 - libstdc++.so.5.0.3 /usr/lib/i486/libstdc++.so.5.0.3 You need to add Qt, kde, and many other libraries to that as well. Essentially, for each C++ library, you should have three versions: the 2.95 version, the c102 version, and the c102-debian version. All default packages are built for i386 (as always) and linked for with the soname libstdc++-i386.so.5. On i486+ systems, the runtime linker will automatically use /usr/lib/i486/libstdc++-i386.so.5, which resolve the __exchange_and_add() function to the trivial assembly version. Isn't the __exchange_and_add function inline, so that the dynamic linker can't change its implementation, anyway? Regards, Martin
Re: i386 compatibility libstdc++
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 28 April 2003 23:54, Martin v. Löwis wrote: Arnd Bergmann [EMAIL PROTECTED] writes: They have to be compiled for i386, as they have always been. If they were compiled for i486, they would not run on i386 anyway, with or without the bug. But if they are compiled for i386, they won't run on other Linux systems, thus losing binary compatibility. If that is important, we can ship an additional library that contains only the i486 __exchange_and_add() code. Ok, I probably wasn't clear enough about the actual trick. If you want to use foreign binaries or build any debian packages libraries with C++ for i486+, you need to install the i486 libstdc++ files. Not only those, but also all other libraries that the executable links with. Why that? Every other library contains either the inline __exchange_and_add code or a reference to the extern one. On i486+ systems, the library builtin function is compatible with the inline one, so it does not matter. If there are any libraries that link statically against libstdc++_pic.a, the optimizations have to match, but AFAICS, we don't do that for regular packages. You need to add Qt, kde, and many other libraries to that as well. Essentially, for each C++ library, you should have three versions: the 2.95 version, the c102 version, and the c102-debian version. That would only be necessary if we would implemented Matthias' original solution where the i386 and i486 versions are neither backwards nor forwards compatible. In my proposal, the i486 version can replace the i386 version, but not vice versa. All default packages are built for i386 (as always) and linked for with the soname libstdc++-i386.so.5. On i486+ systems, the runtime linker will automatically use /usr/lib/i486/libstdc++-i386.so.5, which resolve the __exchange_and_add() function to the trivial assembly version. Isn't the __exchange_and_add function inline, so that the dynamic linker can't change its implementation, anyway? No, look at my patch again. If you build without i486 optimization, the compiler will see only the extern declaration for __exchange_and_add(). Arnd -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+raoF5t5GS2LDRf4RAuo9AJ0YWDiTs15kzn0kelEnPfn5/BhoewCdFXwH nEwqtM+F5lCWSTdpGSUC3gI= =j9Uz -END PGP SIGNATURE-
Re: i386 compatibility libstdc++
At 11:36 28/04/2003 +0200, you wrote: We should still discuss an i686 (or i586) optimized port, but fixing the problem will make it possible to seperate the issues. Indeed! This is (suppossed to be)? just a first step, in order to solve the ABI compatibility issue with libstdc++5 An i586/i686 optimized version could be a high win, by any means. Maybe just to shut up those who say RedHat is faster... :-| Arnd J.L.
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 09:28:53PM -0500, Gunnar Wolf wrote: For practical purposes, yes... Although emulated FP is really, REALLY slow. I installed a machine to be a X terminal about two years ago - 386SX, 8MB RAM. It worked fine, yes... But MUCH slower than a similarly-configured machine with a hardware FP unit, to the point of deciding it would be a text terminal, with no X :) 386DX didn't have the copro either. You needed a '387. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 09:05:50PM -0500, Gunnar Wolf wrote: I agree, the vast majority of our users can afford newer machines. So, I think we should drop m68k, mips and other similar unfashionable old archs, don't you think? The majority of our users will be happy... I'm not sure where the misconception of mips being an old arch comes from. Just look at the au1500 or the R1x000 CPUs. What are criteria for an architecture being old and unfashionable? Regards, -- Guido
Re: i386 compatibility libstdc++
On Sat, 2003-04-26 at 03:56, Chris Cheney wrote: I also find it hard to believe that the majority of our users do not have or can not purchase a system that is less than 7 years old. I have a brand new 486-class system with 32MB of RAM. It's less than 6 months old. Please explain how I can get a similar system, running on a similar amount of power, and with no moving parts (i.e., no fans) using, even a P-II. There are many uses for Debian other than your GNOME or KDE desktop. signature.asc Description: This is a digitally signed message part
Re: i386 compatibility libstdc++
On Sat, 2003-04-26 at 12:15, Steve Langasek wrote: I also find it hard to believe that the majority of our users do not have or can not purchase a system that is less than 7 years old. Your non-sustainable Western consumerism is showing. rant Actually, for most of those old 486's, replacing them with new 486's would be much more sustainable, due to the lessened power draw. /rant Of course, the rest of your post stands. signature.asc Description: This is a digitally signed message part
Re: i386 compatibility libstdc++
On Saturday 26 April 2003 05:08, Chris Cheney wrote: On Sat, Apr 26, 2003 at 09:36:56AM +0800, Cameron Patrick wrote: What about the Via C3? That was introduced not too long ago, runs moderately quickly (~1GHz) with low power consumption, but IIRC doesn't support the i686 instruction set. The issue with this appears to be a gcc bug with respect to compiling for i686: http://marc.theaimsgroup.com/?l=linux-kernelm=104263370505476w=2 Considering cmov optional for i686 seems odd. The only major new operand added from i586-i686 was cmov. In most cases using cmov is a HUGE win because you avoid branching. Even as a owner of a C3 cpu, I would leave C3 on the other side of the fence, slowing down 99% of Athlon/PII users for the sake of 1% of C3 users doesn't make sense.
Re: i386 compatibility libstdc++
Anthony DeRobertis [EMAIL PROTECTED] wrote: [...] rant Actually, for most of those old 486's, replacing them with new 486's would be much more sustainable, due to the lessened power draw. /rant Since manufacturing computers takes _very_ much energy I doubt that. cu andreas
Re: i386 compatibility libstdc++
Matthew Palmer [EMAIL PROTECTED] writes: On 26 Apr 2003, Josselin Mouette wrote: Le sam 26/04/2003 à 02:59, Matthew Palmer a écrit : For the original problem, it surely should be possible to build 386 and 486+ versions of libstdc++ and include both in the distro, with linker magic (or installer magic) to tell the difference? That would not be enough. We need specific versions of C++ applications for 386. Of course, only a few should be enough : python, apt, groff... but that is far from an empty list. That's why dropping i386 completely and provide an i386 subset of the distribution seems reasonable. Whoops, of course. so we'd have ftp.debian.org/ woody main 386only then? Dunno if the autobuilders could handle it, but it'd be one way around it... Couldn't this be solved by using Marcus Brinkmann's architectures-as-dependencies plan? Would this not allow to have several packages, each targetted for different processors? -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: i386 compatibility libstdc++
At 12:52 27/04/2003 -0400, you wrote: On Sat, 2003-04-26 at 03:56, Chris Cheney wrote: I also find it hard to believe that the majority of our users do not have or can not purchase a system that is less than 7 years old. I have a brand new 486-class system with 32MB of RAM. It's less than 6 months old. Please explain how I can get a similar system, running on a similar amount of power, and with no moving parts (i.e., no fans) using, even a P-II. Hey! Where did you get that from? I'd love to have one of those ( specially if they came in a 19 1U form factor or similar !!! ) There are many uses for Debian other than your GNOME or KDE desktop. Surely. This is why i proposed keeping everything compiled for 486 or higher -- that's where the upstream split is, too ... ( we would then need just an small subset of the packages recompiled for i386's libstdc++ ABI ) J.L.
Re: i386 compatibility libstdc++
On Mon, 2003-04-28 at 08:45, José Luis Tallón wrote: At 12:52 27/04/2003 -0400, you wrote: Please explain how I can get a similar system, running on a similar amount of power, and with no moving parts (i.e., no fans) using, even a P-II. Hey! Where did you get that from? I'd love to have one of those ( specially if they came in a 19 1U form factor or similar !!! ) Rack mount? These sorts of things are usually about the size of a pack of playing cards, and aren't intended for use as a stand-alone machine or server: they're often used as embedded systems for industrial monitoring and control, etc. However, even at this level use of the i386 arch is diminishing rapidly, and most of the PC104 etc cards you see around the place are at least 486 or better. My company set up some industrial monitoring units a couple of years ago for a client and we used AMD chips running a very minimal Debian, because the 386 options were just way too underpowered. So speaking as someone with a vested interest in maintaining Debian support for small scale embedded systems, even I wouldn't care if i386 was dropped (at least officially - as someone else noted, running unofficial i386 sources wouldn't be too hard if anyone cared enough to do it). At this point i486 seems to be the minimal ix86 arch worth maintaining, IMHO. Cheers Jonathan
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 02:23:03PM +0200, José Luis Tallón wrote: At 19:55 26/04/2003 +1000, you wrote: On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote: 1a. create a stripped down version for i386, i.e. required/important and go for i486. Is there much performance improvement in dropping i386 in favour of i486+? - Integrated math coprocessor ( why does libc still check for its availability? ) - Cache ( very much needed, i mught add ) - Pipeline attempt IIRC - Mandatory 32bits Bus/Memory IMHO, since we have concluded there are almost NO true i386 around ( not even for routers ), Here is an extract of recent boot messages from one such animal: Apr 22 23:27:43 debian kernel: Linux version 2.4.18 ([EMAIL PROTECTED]) (gcc version 2.95.4 (Debian prerelease)) #1 fre mar 22 02:53:42 CET 2002 [...] Apr 22 23:27:43 debian kernel: Kernel command line: auto BOOT_IMAGE=Linux ro root=301 ether=10,0x300,eth0 ether=9,0x240,eth1 Apr 22 23:27:43 debian kernel: Console: colour VGA+ 80x25 Apr 22 23:27:43 debian kernel: Calibrating delay loop... 3.62 BogoMIPS [...] Apr 22 23:27:45 debian kernel: CPU: 386 Running Woody and acting as a router. There might be more of them than you think. A stripped down version of i386 might actually be a good thing for those of us who still uses 386 machines (with comparably small HD:s) 1a seems appropriate. -- Hans Ekbrand (http://sociologi.cjb.net) [EMAIL PROTECTED] GnuPG key: 1024D/7050614E (currently active subkey 03CE8884) Fingerprint: 1408 C8D5 1E7D 4C9C C27E 014F 7C2C 872A 7050 614E Key available at keyserver.kjsl.com Encrypted emails prefered. pgpDaLioyIySM.pgp Description: PGP signature
Re: i386 compatibility libstdc++
I demand that Gunnar Wolf may or may not have uselessly CC'd to me... [snip] I thought that in-kernel emulation would have solved the gap between 486 DX and SX. For practical purposes, yes... Although emulated FP is really, REALLY slow. Is it safe to mention ARM710 in this thread? :-) -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | Let's keep the pound sterling Hugh of Borg: Resistance is futile. I will assimilate you.
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 05:06:56AM +0200, Arnd Bergmann wrote: The options we currently have are: 1. drop i386 support completely: simple but painful 2. create a crippled distro for really old systems (e.g. i386 and i486) 3. keep everything the i386 way: slow and incompatible 4. like 3, but provide alternatives for new systems (i686+): needs a lot of work and ftp space. No, 4 is not an option -- it would leave too many people in the unnecessarily binary-incompatible bracket. If you want to do a split at 686+ then you need *two* splits, one there and one at, say, 486+. I don't believe it's reasonable to leave people with Pentium-class machines with systems that are not binary-compatible with other distributions, and without the ability to use certain 3rd-party software (in fact I think it's debatable whether or not we could reasonably leave 486 users out in the cold in that way). It may be relatively cheap and easy for *you* to buy a two-year-old system, but I don't believe that in this case you are representative of nearly enough of our users to be a useful example. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Today is the first day of the rest of your life.
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 06:38:34PM +1200, Nick Phillips wrote: It may be relatively cheap and easy for *you* to buy a two-year-old system, but I don't believe that in this case you are representative of nearly enough of our users to be a useful example. I also find it hard to believe that the majority of our users do not have or can not purchase a system that is less than 7 years old. Being that is how old the i686 sub-arch is... I once attempted to install Debian 2.1 on a Pentium 90, it took many hours and was a pita to say the least. Machines old enough to be before i686 are probably also old enough to be barely usable as a desktop, especially since ram prices back then were still quite high (~ $40/MB iirc), and disk sizes quite small (2GB HD was $300 in 1996). What are the theoretical binary-only apps that these desktops would be using, whizbang 3d games, multimedia players, or something else? A reduced size 386-586 arch wouldn't be bad for a server, which imho is about all machines that old are really good for anyway. (And no Manoj I am not attempting to troll with this post...) In Dec 1994 I got my P90 with the biggest available ide hard drive which was 500MB. Compare that size to what sid currently requires for various installs: sid chroot install - 160MB sid standard install - 249MB sid standard + gnome install - 623MB sid standard + kde install - 677MB The point being Debian sid with only one of the standard desktops (with no extra packages and no swap space) is already bigger than most machines from 1995 and older can support unmodified anyway... Chris
Re: i386 compatibility libstdc++
Arnd Bergmann [EMAIL PROTECTED] wrote: [...] 1. drop i386 support completely: simple but painful 2. create a crippled distro for really old systems (e.g. i386 and i486) 3. keep everything the i386 way: slow and incompatible 4. like 3, but provide alternatives for new systems (i686+): needs a lot of work and ftp space. [...] I'd vote for 1 or 1a. create a stripped down version for i386, i.e. required/important and go for i486. The reasoning is simple: Market share. i386 was never that popular as i486 for the simple reason that machines were quite expensive and that i286 was still available (and fast enough for many purposes). cu andreas PS: A simple router might be better off with http://www.zelow.no/floppyfw/ and there is floppy-linux dedicated for ISDN routers too. -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: i386 compatibility libstdc++
On Sat, 26 Apr 2003 17:56, Chris Cheney wrote: I also find it hard to believe that the majority of our users do not have or can not purchase a system that is less than 7 years old. Being that is how old the i686 sub-arch is... I once attempted to install Debian 2.1 on a Pentium 90, it took many hours and was a pita to say the There are also other issues. Currently it seems that Linux code does not get much testing on older hardware. I have a 2.4.20 kernel compiled with recent GCC 3.2.x that runs on a number of Athlon, P2, and P3 machines. But when installed on the single Pentium (non-MMX) machine I run the machine hangs within 6 hours repeatedly. I haven't tracked this down in detail (it's difficult when each test cycle takes several hours and it's a production server). But it's clear to me that something isn't working properly when compiling the latest kernel with the latest GCC for an older Pentium machine. My client (who routinely installs P4 Windows machines for their customers) is not too bothered about being forced to upgrade from a Pentium because of this, they plan to rescue a Celeron that one of their customers discards... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: i386 compatibility libstdc++
W licie z sob, 26-04-2003, godz. 09:56, Chris Cheney pisze: On Sat, Apr 26, 2003 at 06:38:34PM +1200, Nick Phillips wrote: It may be relatively cheap and easy for *you* to buy a two-year-old system, but I don't believe that in this case you are representative of nearly enough of our users to be a useful example. In Dec 1994 I got my P90 with the biggest available ide hard drive which was 500MB. Compare that size to what sid currently requires for various installs: sid chroot install - 160MB sid standard install - 249MB sid standard + gnome install - 623MB sid standard + kde install - 677MB Huh, my first Linux server installation was 386 40MHz 8MB RAM with 2,3GB hard disk which was starting AFAIK in linear mode (it was in RH 6.0 days). But even now FWICS it is quite common to use older hardware with bigger disks, especially as distros tend to be bigger and bigger (my router used to be potato which fit in 80MB HDD quite nicely, but after upgrade to woody I couldn't fit all the previous functionality within those 80MB). Anyway - I am not using any true 386 systems since years, so maybe first solution would be to just make i386 mean i486 and higher. If there's *real* need for i386, then it should be possible to create i386true sub-distro in the future. Just my 0.02$ Grzegorz B. Prokopski PS: Do not make no jokes about running KDE/GNOME on i386true :-) -- Grzegorz B. Prokopski [EMAIL PROTECTED] Debian http://www.debian.org/ signature.asc Description: PGP signature
Re: i386 compatibility libstdc++
On Fri, 2003-04-25 at 21:37, Josselin Mouette wrote: Le sam 26/04/2003 02:59, Matthew Palmer a crit : For the original problem, it surely should be possible to build 386 and 486+ versions of libstdc++ and include both in the distro, with linker magic (or installer magic) to tell the difference? That would not be enough. We need specific versions of C++ applications for 386. Of course, only a few should be enough : python, apt, groff... but that is far from an empty list. That's why dropping i386 completely and provide an i386 subset of the distribution seems reasonable. Agreed. It seems to me though that we've just traded one problem (i386) for another: our poor archive categorization. How to define this distribution subset?
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote: I'd vote for 1 or 1a. create a stripped down version for i386, i.e. required/important and go for i486. I'll drink to that! -- Nick Phillips -- [EMAIL PROTECTED] You are confused; but this is your normal state.
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 02:56:13AM -0500, Chris Cheney wrote: I also find it hard to believe that the majority of our users do not have or can not purchase a system that is less than 7 years old. That's really not so relevant, even if correct. If they already have a shitload of Pentiums which will do the job, why force them to buy anything newer? Being that is how old the i686 sub-arch is... I once attempted to install Debian 2.1 on a Pentium 90, it took many hours and was a pita to say the least. Heh. I once (no, twice) installed on a 486-50 with 4MB of RAM... :-P I can't remember whether that was slink, or whether I got hold of slink after being suitably impressed with the results (had to leave dselect running^Wthrashing for round about 36 hours, I think, for the initial install ;) ). That's actually what got me started moving from slackware to Debian... Anyway, back to the point. Machines old enough to be before i686 are probably also old enough to be barely usable as a desktop, I think you'll find they'll do just fine in all sorts of roles. Perhaps not as a whizzy desktop running the latest greatest KDE or Gnome (resisting the temptation, see ;) ), but certainly running X (although I must admit XFree = 4 is a real memory hog compared to previous versions). What are the theoretical binary-only apps that these desktops would be using, whizbang 3d games, multimedia players, or something else? Whizbang 3d games and multimedia players are not the only things that people write in C++. A reduced size 386-586 arch wouldn't be bad for a server, which imho is about all machines that old are really good for anyway. (And no Manoj I am not attempting to troll with this post...) See, I think this is where you're just fundamentally mistaken. In Dec 1994 I got my P90 with the biggest available ide hard drive which was 500MB. :-P No it wasn't. You must have been shopping in the wrong places. I got my 486DX66 with a 504MB drive in mid '93 and had the option of a bigger one (~1G I think, but can't remember exactly)... Compare that size to what sid currently requires for various installs: sid chroot install - 160MB sid standard install - 249MB Perfectly fine. I think I'll have to finish the install on this P200MMX I have sitting under my desk here just to see how big it does end up. The point being Debian sid with only one of the standard desktops (with no extra packages and no swap space) is already bigger than most machines from 1995 and older can support unmodified anyway... Whilst I don't see that the standard desktops are at all essential to a productive setup, I will agree that it is a shame how large the standard installs are getting. I think there will come a point where it is more useful to have a separate distribution or meta-distribution for older systems (with a sensible-sized libc, for example) than to stick with a one size fits all approach. I just don't think that with the quantity of Pentium-class machines out there that we've got to that point just yet. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Give him an evasive answer.
Re: i386 compatibility libstdc++
* Russell Coker | My logtools package is written in C++ with the STL. It performs | well and will be quite useful to anyone who is running Apache for | multiple domains on a 386. No offense, but it is seriously slow. IIRC, it's a magnitude slower than mergelog, especially when merging a lot of files. (And having FILE_MAX set to 1024 is ridiculously low when merging a lot of log files :) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote: 1a. create a stripped down version for i386, i.e. required/important and go for i486. Is there much performance improvement in dropping i386 in favour of i486+? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: i386 compatibility libstdc++
Hamish Moffatt [EMAIL PROTECTED] wrote: On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote: 1a. create a stripped down version for i386, i.e. required/important and go for i486. Is there much performance improvement in dropping i386 in favour of i486+? I've no idea, I was arguing for splitting off i386 because it solves the original problem. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: i386 compatibility libstdc++
At 19:55 26/04/2003 +1000, you wrote: On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote: 1a. create a stripped down version for i386, i.e. required/important and go for i486. Is there much performance improvement in dropping i386 in favour of i486+? - Integrated math coprocessor ( why does libc still check for its availability? ) - Cache ( very much needed, i mught add ) - Pipeline attempt IIRC - Mandatory 32bits Bus/Memory IMHO, since we have concluded there are almost NO true i386 around ( not even for routers ), the first *easy* split would be to drop i386 in favour of i486 for Sarge+ ( does anybody really think i386 will survive another year/year-and-a-half ?? ). This will solve the ABI problem in one, easy, shot This means binary-i386 in Debian will really mean binary-i486 -- I don't see any problems here. We might then try to judge how much of a benefit we can get by moving on to i586+ for the vast majority of the archive ( other distributions support i586+ *only*, so it can't be that bad, can it? ). Retiring i586 right now looks a bit bold to be done right now. I do own a (retired now) 486, with 16MB -- it was really a pain when i last used it[ 2years ago], with SuSE 6.2 [released 1998]. These machines are only good for routers now, which means we could create a subarch, with just the kernel, basic libs, iptables, ssh, security tools and things like that (maybe Postfix/exim/sendmail ? ) -- no need for Apache, nor MySQL/PostgreSQL ( !!! ), especially no need for XFree, Gnome, KDE et al -- and everything would be fine. As a side effect, we would get the basic installation size down to about 50-65MB ( just guessing! ): this can only be an improvement. The smaller machines me or any of my friends/relatives/acquaintances are using are P90 w/32MB, loaded with say, 120GB IDE HDD -- used as servers connected to cable/ADSL lines, running mldonkey, ftp servers, grin -- All running Woody :D This means we shouldn't leave that *whole lot* of users without frequent security updates for Apache, Postfix/exim, proftpd, ... Regards, J.L.
Re: i386 compatibility libstdc++
* Grzegorz B. Prokopski [EMAIL PROTECTED] [030426 04:45]: Anyway - I am not using any true 386 systems since years, so maybe first solution would be to just make i386 mean i486 and higher. If there's *real* need for i386, then it should be possible to create i386true sub-distro in the future. That sounds very inappropriate not to mention confusing. Besides, we already have a synonym for i486 and higher, it's i486. B. -- WebSig: http://www.jukie.net/~bart/sig/ pgpkgUe1OUuKK.pgp Description: PGP signature
Re: i386 compatibility libstdc++
I demand that José Luis Tallón may or may not have written... At 19:55 26/04/2003 +1000, you wrote: On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote: 1a. create a stripped down version for i386, i.e. required/important and go for i486. Is there much performance improvement in dropping i386 in favour of i486+? - Integrated math coprocessor ( why does libc still check for its availability? ) [...] 486SX. -- | Darren Salt | nr. Ashington, | linux (or ds) at | woody, sarge, | Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | We've got Shearer, you haven't You are taking yourself too seriously.
Re: i386 compatibility libstdc++
* Hamish Moffatt [EMAIL PROTECTED] [030426 05:57]: On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote: 1a. create a stripped down version for i386, i.e. required/important and go for i486. Is there much performance improvement in dropping i386 in favour of i486+? For openssl there is a huge improvement. I was doing benchmarks on openssl (they were done for internally at a company I no longer work for). We were using P3's at the time. The highest performance gain was between i386-i486 for varied ciphers; that is to say going to i586 or i686 (with gcc2.9x) was not that much better. Take this with a grain of salt... this may actually have something to do with openssl having canned ASM implementations for some ciphers on some architectures, but I am not sure about that. B. -- WebSig: http://www.jukie.net/~bart/sig/ pgpMdscIMu4LI.pgp Description: PGP signature
Re: i386 compatibility libstdc++
In chiark.mail.debian.devel, Matthias Klose wrote: - Trying to fix this resulted in libstdc++5 packages built for i386 and ix86, and selecting the atomicity implementation based on target cpu macros. This approach doesn't work, as I learned now. See http://gcc.gnu.org/ml/libstdc++/2003-04/msg00394.html: It's not possible to mix the two implementations. Is it possible to fix this (ie, provide ABI compatible versions for i386 and i486) without breaking stuff? 386s are faster than many other pieces of hardware that we still support, so dropping them seems strange - on the other hand, an i386 sub-distribution sounds like a world of pain. Having a standard library that only supports one of the allegedly supported processors if the ABI changes sounds like the real bug to me. -- Matthew Garrett | [EMAIL PROTECTED]
Re: i386 compatibility libstdc++
* Darren Salt [EMAIL PROTECTED] [030426 10:26]: I demand that José Luis Tallón may or may not have written... At 19:55 26/04/2003 +1000, you wrote: On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote: 1a. create a stripped down version for i386, i.e. required/important and go for i486. Is there much performance improvement in dropping i386 in favour of i486+? - Integrated math coprocessor ( why does libc still check for its availability? ) [...] 486SX. I thought that in-kernel emulation would have solved the gap between 486 DX and SX. B. -- WebSig: http://www.jukie.net/~bart/sig/ pgpSjyH3NcIVN.pgp Description: PGP signature
Re: i386 compatibility libstdc++
At 14:17 26/04/2003 +0100, you wrote: I demand that José Luis Tallón may or may not have written... At 19:55 26/04/2003 +1000, you wrote: On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote: 1a. create a stripped down version for i386, i.e. required/important and go for i486. Is there much performance improvement in dropping i386 in favour of i486+? - Integrated math coprocessor ( why does libc still check for its availability? ) [...] 486SX. Though I own one, these are not exactly *full* 486, but just the low-cost version... -- | Darren Salt | nr. Ashington, | linux (or ds) at | woody, sarge, | Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | We've got Shearer, you haven't You are taking yourself too seriously. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 10:08:12AM -0400, Bart Trojanowski wrote: For openssl there is a huge improvement. I was doing benchmarks on openssl (they were done for internally at a company I no longer work OpenSSL can (and already does) drop in the CPU-specific variants at run time in an ABI-compatible fashion. -- You grabbed my hand and we fell into it, like a daydream - or a fever. pgprX89DkTfRV.pgp Description: PGP signature
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 10:55:08AM -0400, Bart Trojanowski wrote: * Darren Salt [EMAIL PROTECTED] [030426 10:26]: 486SX. I thought that in-kernel emulation would have solved the gap between 486 DX and SX. It works just as well for 386SX as for 486SX. -- You grabbed my hand and we fell into it, like a daydream - or a fever. pgpk6yuJTCti0.pgp Description: PGP signature
Re: i386 compatibility libstdc++
I demand that Bart Trojanowski may or may not have CCed to me WITHOUT MY ASKING FOR THAT... * Darren Salt [EMAIL PROTECTED] [030426 10:26]: I demand that José Luis Tallón may or may not have written... At 19:55 26/04/2003 +1000, you wrote: On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote: 1a. create a stripped down version for i386, i.e. required/important and go for i486. Is there much performance improvement in dropping i386 in favour of i486+? - Integrated math coprocessor ( why does libc still check for its availability? ) [...] 486SX. I thought that in-kernel emulation would have solved the gap between 486 DX and SX. Good point... Unless there's some code which is only worth using in the absence of hardware FP :-) -- | Darren Salt | nr. Ashington, | linux (or ds) at | woody, sarge, | Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | Scumderland 0 Newcastle United 1 :-) YES! GET IN! WAHEY! Etc.
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 02:56:13AM -0500, Chris Cheney wrote: On Sat, Apr 26, 2003 at 06:38:34PM +1200, Nick Phillips wrote: It may be relatively cheap and easy for *you* to buy a two-year-old system, but I don't believe that in this case you are representative of nearly enough of our users to be a useful example. I also find it hard to believe that the majority of our users do not have or can not purchase a system that is less than 7 years old. Your non-sustainable Western consumerism is showing. Machines old enough to be before i686 are probably also old enough to be barely usable as a desktop, especially since ram prices back then were still quite high (~ $40/MB iirc), and disk sizes quite small (2GB HD was $300 in 1996). What are the theoretical binary-only apps that these desktops would be using, whizbang 3d games, multimedia players, or something else? A reduced size 386-586 arch wouldn't be bad for a server, which imho is about all machines that old are really good for anyway. (And no Manoj I am not attempting to troll with this post...) Though I don't think we have to worry about binary-only C++ apps for 486 and 586 machines, AIUI the whole reason there are two binary-incompatible implementations is that one gives a performance gain on newer systems. Users of lower-end systems that are already limping deserve a chance at seeing some of these performance benefits, the same as users of newer systems. As for using i486s and i586s as anything other than servers, I'm currently involved in a project whose goal is to put surplus PC and Mac hardware running free (as in beer) software into the hands of disadvantaged members of the community. I also know of a church locally that was considering the adoption of Debian for the PCs they ship to West Africa (just add electricity) as part of their mission work. While neither of these scenarios demands cutting-edge software or frequent security updates, it would be nice to be able to provide such users with an OS that can keep pace with the shifting protocol soup of the Internet. If it's a call between tossing updates and tossing the donated 486s, though, the hardware stays. -- Steve Langasek postmodern programmer pgpVFfyUaoOBv.pgp Description: PGP signature
Re: i386 compatibility libstdc++
Hi, On Sat, Apr 26, 2003 at 05:07:41PM +0100, Mark Brown wrote: On Sat, Apr 26, 2003 at 10:55:08AM -0400, Bart Trojanowski wrote: * Darren Salt [EMAIL PROTECTED] [030426 10:26]: 486SX. I thought that in-kernel emulation would have solved the gap between 486 DX and SX. It works just as well for 386SX as for 486SX. Note that the SX suffix for 386 means a 16-bit external data bus (instead of a 32-bit one for the DX), whereas for 486 the SX means no FP included. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: i386 compatibility libstdc++
* Mark Brown [EMAIL PROTECTED] [030426 12:21]: On Sat, Apr 26, 2003 at 10:08:12AM -0400, Bart Trojanowski wrote: For openssl there is a huge improvement. I was doing benchmarks on openssl (they were done for internally at a company I no longer work OpenSSL can (and already does) drop in the CPU-specific variants at run time in an ABI-compatible fashion. This question is obviously off topic for this thread but I am interested... re 'at run time': Does that mean that at compile time there are multiple snippets of functionally-equivalent code compiled to support varied run-time arch's? I have not looked the the OpenSSL code in a while. :) B. -- WebSig: http://www.jukie.net/~bart/sig/ pgp5utoeRk3RY.pgp Description: PGP signature
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 12:53:04PM -0400, Bart Trojanowski wrote: re 'at run time': Does that mean that at compile time there are multiple snippets of functionally-equivalent code compiled to support varied run-time arch's? The support is actually in the runtime linker. libssl is compiled multiple times with CPU-optimized versions installed into subdirectories of /usr/lib indicating the CPU type. While doing runtime linking ld.so looks first in the CPU-specific subdirectories. This only works if the ABIs of the libraries are interchangable. -- You grabbed my hand and we fell into it, like a daydream - or a fever. pgp6O8sC8kgKo.pgp Description: PGP signature
Re: i386 compatibility libstdc++
It may be relatively cheap and easy for *you* to buy a two-year-old system, but I don't believe that in this case you are representative of nearly enough of our users to be a useful example. I also find it hard to believe that the majority of our users do not have or can not purchase a system that is less than 7 years old. Being that is how old the i686 sub-arch is... I once attempted to install Debian 2.1 on a Pentium 90, it took many hours and was a pita to say the least. Machines old enough to be before i686 are probably also old enough to be barely usable as a desktop, especially since ram prices back then were still quite high (~ $40/MB iirc), and disk sizes quite small (2GB HD was $300 in 1996). What are the theoretical binary-only apps that these desktops would be using, whizbang 3d games, multimedia players, or something else? A reduced size 386-586 arch wouldn't be bad for a server, which imho is about all machines that old are really good for anyway. (And no Manoj I am not attempting to troll with this post...) I agree, the vast majority of our users can afford newer machines. So, I think we should drop m68k, mips and other similar unfashionable old archs, don't you think? The majority of our users will be happy... I would not do that. First of all, many of us do have quite old and useful machines. Lots of people use 386/486 machines as home gateways - even mission-critical gateways at the office, those machines are still enough to handle E1 level traffic. And... Well, at my gateway at home (i486) I have Samba, Bind and Apache running - And quite smoothly. If we have to split somehow what should be supported for i386-old and what should require i386-fast, we will find out many users who found a creative use for their old hardware. Debian is about choice - we should do our best to let the *user* choose what he can and can not do with his old machine. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: i386 compatibility libstdc++
1a. create a stripped down version for i386, i.e. required/important and go for i486. Is there much performance improvement in dropping i386 in favour of i486+? - Integrated math coprocessor ( why does libc still check for its availability? ) [...] 486SX. I thought that in-kernel emulation would have solved the gap between 486 DX and SX. For practical purposes, yes... Although emulated FP is really, REALLY slow. I installed a machine to be a X terminal about two years ago - 386SX, 8MB RAM. It worked fine, yes... But MUCH slower than a similarly-configured machine with a hardware FP unit, to the point of deciding it would be a text terminal, with no X :) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF pgp331Hzham4J.pgp Description: PGP signature
Re: i386 compatibility libstdc++
* Gunnar Wolf [EMAIL PROTECTED] [030426 22:29]: 1a. create a stripped down version for i386, i.e. required/important and go for i486. Is there much performance improvement in dropping i386 in favour of i486+? - Integrated math coprocessor ( why does libc still check for its availability? ) [...] 486SX. I thought that in-kernel emulation would have solved the gap between 486 DX and SX. For practical purposes, yes... Although emulated FP is really, REALLY slow. I installed a machine to be a X terminal about two years ago - 386SX, 8MB RAM. It worked fine, yes... But MUCH slower than a similarly-configured machine with a hardware FP unit, to the point of deciding it would be a text terminal, with no X :) I agree completely -- in todays world of CPU's capable of many millions of FP operations/s you really don't want a 486SX. However, in the context of our conversation it makes no difference that the performance sucks. A 486 is a 486 as far as a Debian package is concerned. We don't need to consider the 486SX when deciding where the architecture split should be. B. -- WebSig: http://www.jukie.net/~bart/sig/ pgpFlLXGMqJ8E.pgp Description: PGP signature
i386 compatibility libstdc++
Should Debian further support the i386 target, or make (at least i486) the default for code generation? Asking because I'm unsure how to provide the libstdc++5 package. - In gcc-3.2, the libstdc++ atomicity implementation uses ix86 (=4) specific code. This was reported by two users (#184446, #185662). - In gcc-3.3, it's differentiated between i386 and ix86 (=4), however the atomicity implementation is selected at configure time (so an i386-linux configured compiler always uses the generic implementation). - Trying to fix this resulted in libstdc++5 packages built for i386 and ix86, and selecting the atomicity implementation based on target cpu macros. This approach doesn't work, as I learned now. See http://gcc.gnu.org/ml/libstdc++/2003-04/msg00394.html: It's not possible to mix the two implementations. - Keeping the generic implementation would not allow binaries linked against the libstdc++ built with the generic implementation to run on platforms with a libstdc++ built for ix86 (=4). See #189983. No libstdc++ dependent binary will run on distributions optimized for ix86 (=4). - The generic implementation hurts ix86 (=4) users a bit more. Phil Edwards writes in #184446: Debian already hurts the x86 users (IMHO) by giving them a compiler targetted for processor which, I'd bet, is used by less than 2% of the user base. This is just one more performace hit on top of all the others; I really wouldn't worry about it unless/until the compiler is targeted to something more useful, e.g., i486, i586, or (quelle suprise) i686, and for those cases the atomic operations will be automatically corrected. For now I will revert to the gcc-3.2 implementation and continue beeing incompatible with i386. But if you do this, why not make i486 the default target for code generation anyway? Who decides on this, is there an ix86 port maintainer? Matthias
Re: i386 compatibility libstdc++
Matthias Klose [EMAIL PROTECTED] wrote: [...] - In gcc-3.2, the libstdc++ atomicity implementation uses ix86 (=4) specific code. This was reported by two users (#184446, #185662). [...] - Keeping the generic implementation would not allow binaries linked against the libstdc++ built with the generic implementation to run on platforms with a libstdc++ built for ix86 (=4). See #189983. No libstdc++ dependent binary will run on distributions optimized for ix86 (=4). [...] Are there problems the other way round, too? For now I will revert to the gcc-3.2 implementation and continue beeing incompatible with i386. [...] Does anybody know how/if other Distributions reacted to this issue? Suse, Redhat et.al. afaik have been using gcc-3.x for more than one release. cu andreas
Re: i386 compatibility libstdc++
Andreas Metzler wrote: Does anybody know how/if other Distributions reacted to this issue? Suse, Redhat et.al. afaik have been using gcc-3.x for more than one release. They just don't support i386 anymore. http://www.suse.de/en/private/products/suse_linux/i386/system_requirements.html http://www.redhat.com/software/linux/technical/ You got to have a Pentium+ for these distributions. This is quite reasonable, IMO: People with older hardware can use older versions of these distributions (which they are running probably already, anyway). Regards, Martin
Re: i386 compatibility libstdc++
On pe, 2003-04-25 at 11:09, Martin v. Löwis wrote: They just don't support i386 anymore. http://www.suse.de/en/private/products/suse_linux/i386/system_requirements.html http://www.redhat.com/software/linux/technical/ You got to have a Pentium+ for these distributions. This is quite reasonable, IMO: People with older hardware can use older versions of these distributions (which they are running probably already, anyway). So using a 386 as a router and firewall, which it is perfectly capable of hardwarewise, isn't going to be an option anymore? For such purposes, running an older version of Debian (or whatever distribution) isn't an option, since you have to be able to get security updates. I could live with that, but I think it'd be a shame. -- Enemies of Carlotta 1.0 mailing list manager: http://liw.iki.fi/liw/eoc/
Re: i386 compatibility libstdc++
Lars Wirzenius wrote: So using a 386 as a router and firewall, which it is perfectly capable of hardwarewise Is that really the case? a) Is anybody actually doing this, today? b) Do you then have 10MB or 100MB ethernet in that computer? Can you even put a 100MB ethernet card into the computer? Does it have PCI? I really don't recall the answers to these questions, since it is such a long time that I have last seen a real 386 machine. If there is enough userbase for an i386 distribution, I wouldn't mind if an i386 port was maintained separately. However, I really think it would be a good thing if Linux could, in general, assume 486+ (or perhaps even Pentium+). Regards, Martin
Re: i386 compatibility libstdc++
On Fri, 25 Apr 2003 20:09, Martin v. Löwis wrote: Lars Wirzenius wrote: So using a 386 as a router and firewall, which it is perfectly capable of hardwarewise Is that really the case? a) Is anybody actually doing this, today? b) Do you then have 10MB or 100MB ethernet in that computer? Can you even put a 100MB ethernet card into the computer? Does it have PCI? The first PCI machines were 486 based. The early 486 machines used EISA bus, VL in addition to ISA, or maybe plain ISA. The 486 came out before the PCI bus. When the 486 hit it's peak (486-100 class machines) the PCI bus was just beginning. I have not seen or heard of a 386-PCI system, although they may be used for some special applications (not commodity PCs). A 386 with an ISA bus could not get full bandwidth out of 10baseT. I don't recall seeing anything better than about 600KB/s, although with a recent kernel I'm sure you could get better than that I doubt it would be a full 10megabit. If there is enough userbase for an i386 distribution, I wouldn't mind if an i386 port was maintained separately. However, I really think it would be a good thing if Linux could, in general, assume 486+ (or perhaps even Pentium+). It does sound like it would be a good idea to have a separate build for 386 and 486, then we could optimise everything else for 586+. We can even use P2 machines for build daemons so we wouldn't have the speed problems we have with M68K... :-# -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: i386 compatibility libstdc++
Hi, On Fri, 25 Apr 2003 09:13:08 +, Lars Wirzenius wrote: I could live with that, but I think it'd be a shame. Hmm. Did anybody measure the performance increase in a typical userspace-CPU-intensive program when built with i586-only options (as opposed to optimize for i586+ but generate compatible code)? FWIW, I don't have an i386 box any more either, but all the same I'm against dropping Debian support for them. -- Matthias
Re: i386 compatibility libstdc++
On Fri, Apr 25, 2003 at 12:09:21PM +0200, Martin v. Löwis wrote: So using a 386 as a router and firewall, which it is perfectly capable of hardwarewise Is that really the case? a) Is anybody actually doing this, today? In our company, we are using * Two 386sx 16 MHz with 8 MB RAM as DNS (authoritative, secondary for a handful of domains) * A 386DX 40 MHz as ISDN logging machine (equipped with a ISA ISDN card, running isdnlog to make a log of all incoming and outgoing calls) * A 486 as backup server (using big IDE drives for data storage) All running woody and latest 2.2.x kernels. b) Do you then have 10MB or 100MB ethernet in that computer? Can you even put a 100MB ethernet card into the computer? Does it have PCI? There are 100MB ISA cards, but the 386 can't use their full capacity. The machines I mentionned above use 10MB ISA ethernet cards. -- Andreas Trottmann Ideen Werft22 GmbH Tel+41 (0)56 210 91 37 Fax+41 (0)56 210 91 34 Mobile +41 (0)79 229 88 55
Re: i386 compatibility libstdc++
On Fri, Apr 25, 2003 at 12:13:08PM +0300, Lars Wirzenius wrote: On pe, 2003-04-25 at 11:09, Martin v. L?wis wrote: They just don't support i386 anymore. http://www.suse.de/en/private/products/suse_linux/i386/system_requirements.html http://www.redhat.com/software/linux/technical/ You got to have a Pentium+ for these distributions. This is quite reasonable, IMO: People with older hardware can use older versions of these distributions (which they are running probably already, anyway). So using a 386 as a router and firewall, which it is perfectly capable of hardwarewise, isn't going to be an option anymore? For such purposes, running an older version of Debian (or whatever distribution) isn't an option, since you have to be able to get security updates. I could live with that, but I think it'd be a shame. I bet someone would rebuild base+some extras using i386 target compiler and make it available, if Debian did that. They would probably serve a few hundred users total, at best. I don't think it would be too much to expect debian-i386 to become a side-project. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Re: i386 compatibility libstdc++
Hi, On Fri, Apr 25, 2003 at 08:53:40PM +1000, Russell Coker wrote: It does sound like it would be a good idea to have a separate build for 386 and 486, then we could optimise everything else for 586+. Hmm... I'd argue for putting the split at either 386 vs 486+ (the latter at least has a math copro and CMPXCHG), or at 386-pentium vs 686+. I say this because the original pentium didn't introduce a lot of new features other than the two pipelines for which you only need some insn scheduling that's fully compatible with the 486, and IIRC wasn't sold nearly as well as the various flavours of the 486. In other words, if you use 486-compatible instructions and pentium scheduling, you're already taking almost full advantage of the pentium. It makes therefore little sense to group the original pentium with the later architectures. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpkpnAaCa13L.pgp Description: PGP signature
Re: i386 compatibility libstdc++
* Martin v. L?wis ([EMAIL PROTECTED]) wrote: Lars Wirzenius wrote: So using a 386 as a router and firewall, which it is perfectly capable of hardwarewise Is that really the case? Yes. a) Is anybody actually doing this, today? Yes. b) Do you then have 10MB or 100MB ethernet in that computer? Can you even put a 100MB ethernet card into the computer? Does it have PCI? If you've only got a 1.5Mb/s max connection to the internet a 386 can handle it just fine. You can put 100Mb/s ethernet cards in a 386 using the ISA bus and a 3c515 card. It can't get 100Mb/s speeds of course but as I recall it can get above 10Mb/s. Again, not that it matters if the uplink speed is slow. I really don't recall the answers to these questions, since it is such a long time that I have last seen a real 386 machine. I've got a 386 here that I'm not currently using but is still in perfectly working order. A friend of mine has a 386 being used as a firewall under 2.4 for his ADSL connection. I've got a 486 which is currently being used as a mail relay server (which obviously needs security updates) and an original pentium box as my gateway. My dad has a 486 for his firewall on his ADSL connection which I set up for him. 386's seemed to be faster than m68k machines from what I saw when I last had my m68k box up and running. If there is enough userbase for an i386 distribution, I wouldn't mind if an i386 port was maintained separately. However, I really think it would be a good thing if Linux could, in general, assume 486+ (or perhaps even Pentium+). Having multiple ports based on intelligent break-points in the x86 architecture could make sense. I say intelligent break-points because it might make more sense to have a '386' version and a '586' version and that's it rather than have one for every arch type gcc has. I'm sure there's a tradeoff between disk space and buildd time and other factors and if a given arch really improved things that much. Stephen pgpPqEKUtl5FQ.pgp Description: PGP signature
Re: i386 compatibility libstdc++
Matthias Urlichs wrote: Hmm. Did anybody measure the performance increase in a typical userspace-CPU-intensive program when built with i586-only options (as opposed to optimize for i586+ but generate compatible code)? In the current issue, it is not that much a question of performance, but of correctness: the two versions of libstdc++ aren't mutually binary-compatible, so Debian needs to decide whether to support i386 or compatibility with other distributions (and thus likely upcoming jdks etc) - you can't have both. Regards, Martin
Re: i386 compatibility libstdc++
Martin v. Lwis [EMAIL PROTECTED] writes: Lars Wirzenius wrote: So using a 386 as a router and firewall, which it is perfectly capable of hardwarewise [snip] b) Do you then have 10MB or 100MB ethernet in that computer? Can you even put a 100MB ethernet card into the computer? Does it have PCI? There are 100Mb/s ISA cards, such as the 3c515. I have one of those in a 486 at home. Not that you'd want a 386 (or a 486, for that matter) as a router for such a big pipe, but for modem/ISDN/ADSL speeds it should do just fine. -- ilmari
Re: i386 compatibility libstdc++
On Fri, Apr 25, 2003 at 08:51:41AM +0200, Matthias Klose wrote: Should Debian further support the i386 target, or make (at least i486) the default for code generation? Asking because I'm unsure how to provide the libstdc++5 package. FWIW, hurd-i386 doesn't now, nor will it likely ever run on i386. We're i486 (with a co-processor) and above. Tks, Jeff Bailey -- You said homosexuals form a small percentage of the population. So do Jews. Is that a reason to deny someone equality? - Richard Marceau
Re: i386 compatibility libstdc++
On Fri, Apr 25, 2003 at 01:37:04PM +0200, Emile van Bergen wrote: I say this because the original pentium didn't introduce a lot of new features other than the two pipelines for which you only need some insn scheduling that's fully compatible with the 486, and IIRC wasn't sold nearly as well as the various flavours of the 486. In other words, if you use 486-compatible instructions and pentium scheduling, you're already taking almost full advantage of the pentium. It makes therefore little sense to group the original pentium with the later architectures. The problem with this is the binary compatibility with other distributions, and the availability (or more likely, not) of third party binary-only software built against 386 versions of libs. Breaking at 686+ would mean that people with reasonably capable Pentium/MMX machines (say a P200MMX) would likely be unable to use such software. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] You feel a whole lot more like you do now than you did when you used to.
Re: i386 compatibility libstdc++
On Fri, Apr 25, 2003 at 09:32:05AM +0200, Andreas Metzler wrote: Does anybody know how/if other Distributions reacted to this issue? Suse, Redhat et.al. afaik have been using gcc-3.x for more than one release. Minimum: Pentium-class http://www.redhat.com/software/linux/technical/ I can't find any CPU requirements (or installation documentation, for that matter) for SuSE, but I think they do the same. -- - mdz
Re: i386 compatibility libstdc++
On Fri, Apr 25, 2003 at 07:30:34AM -0400, Ben Collins wrote: I bet someone would rebuild base+some extras using i386 target compiler and make it available, if Debian did that. They would probably serve a few hundred users total, at best. I don't think it would be too much to expect debian-i386 to become a side-project. I agree that it would not be too much to expect, but if we can step back support for i386 without forcing it to become a side project, that seems better. If we were to provide (for example) only a strict subset of packages, this seems similar to what we need for (e.g.) sparc64. -- - mdz
Re: i386 compatibility libstdc++
On Fri, Apr 25, 2003 at 01:37:04PM +0200, Emile van Bergen wrote: Hmm... I'd argue for putting the split at either 386 vs 486+ (the latter at least has a math copro and CMPXCHG), or at 386-pentium vs 686+. See the beginning of this thread; the problem is that libstdc++ has drawn a line between 386 and 486. -- - mdz
Re: i386 compatibility libstdc++
Ben Collins wrote: I bet someone would rebuild base+some extras using i386 target compiler and make it available, if Debian did that. They would probably serve a few hundred users total, at best. I don't think it would be too much to expect debian-i386 to become a side-project. debian-i386 could be a much smaller distro, too. Is anyone really running XFree86 4.2 or similarly heavyweight programs on such ancient machines? The slowest machine I ever work with these days is an old Pentium-90 with 32 MB RAM. I won't even put X on that anymore, though it did have X back when it was my only Linux machine. Craig pgpw6hHv8lgmE.pgp Description: PGP signature
Re: i386 compatibility libstdc++
On Fri, Apr 25, 2003 at 08:51:41AM +0200, Matthias Klose wrote: Should Debian further support the i386 target, or make (at least i486) the default for code generation? Asking because I'm unsure how to provide the libstdc++5 package. Realistically, are there any C++ apps on the planet that wouldn't choke an i386 to death anyway? -- Steve Langasek postmodern programmer pgpOybbCKQuNn.pgp Description: PGP signature
Re: i386 compatibility libstdc++
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 25 April 2003 15:43, Matt Zimmerman wrote: On Fri, Apr 25, 2003 at 01:37:04PM +0200, Emile van Bergen wrote: Hmm... I'd argue for putting the split at either 386 vs 486+ (the latter at least has a math copro and CMPXCHG), or at 386-pentium vs 686+. See the beginning of this thread; the problem is that libstdc++ has drawn a line between 386 and 486. No, the only thing that is enforced is that i386 systems cannot use the i486+ ABI. It is a very possible solution to have use the i386 ABI on any system and the i486+ ABI only on i686+. That will however mean that third party software using libstdc++5 with the i486 ABI won't work will not work on systems with an instruction set older than i686. It's a compromise, but I think it's still better than forcing everyone on the i486 compatibility that is just as obsolete as i386 (i.e. you won't buy any _new_ i486 machines in order to run Debian). If we really want to split i386 in 'compatible' and 'fast', the i686 border makes sense because users who care about speed probably bought the machine during the last two years and those should be i686 compatible. Arnd -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+qU7d5t5GS2LDRf4RAnmSAJwP8KmZKSz9O/agZm6827j+1J8OdACgpi/g lYTHdiTQ3t00foJnCCFSY18= =6j4f -END PGP SIGNATURE-
Re: i386 compatibility libstdc++
On Fri, Apr 25, 2003 at 09:26:41AM -0500, Steve Langasek wrote: On Fri, Apr 25, 2003 at 08:51:41AM +0200, Matthias Klose wrote: Should Debian further support the i386 target, or make (at least i486) the default for code generation? Asking because I'm unsure how to provide the libstdc++5 package. Realistically, are there any C++ apps on the planet that wouldn't choke an i386 to death anyway? groff wouldn't be *that* bad, I don't think ... -- Colin Watson [EMAIL PROTECTED]
Re: i386 compatibility libstdc++
Hi, On Fri, Apr 25, 2003 at 09:26:41AM -0500, Steve Langasek wrote: On Fri, Apr 25, 2003 at 08:51:41AM +0200, Matthias Klose wrote: Should Debian further support the i386 target, or make (at least i486) the default for code generation? Asking because I'm unsure how to provide the libstdc++5 package. Realistically, are there any C++ apps on the planet that wouldn't choke an i386 to death anyway? There's nothing wrong with the performance of C++ apps. Years ago I did lots of C++ development on a 16MHz 386SX running DOS. The problem is STL and the fact that a lot of C++ programmers tend to forget to conquer while dividing. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpurcLir9xvi.pgp Description: PGP signature
Re: i386 compatibility libstdc++
On Fri, Apr 25, 2003 at 04:36:00PM +0100, Colin Watson wrote: On Fri, Apr 25, 2003 at 09:26:41AM -0500, Steve Langasek wrote: On Fri, Apr 25, 2003 at 08:51:41AM +0200, Matthias Klose wrote: Should Debian further support the i386 target, or make (at least i486) the default for code generation? Asking because I'm unsure how to provide the libstdc++5 package. Realistically, are there any C++ apps on the planet that wouldn't choke an i386 to death anyway? groff wouldn't be *that* bad, I don't think ... It had to be pointed out to me that, choking or not, apt is also fairly important to have on the system. :) So perhaps a sub-port consisting of a static libstdc++ library, together with statically-linked versions of groff and apt, would satisfy the needs of i386 users? -- Steve Langasek postmodern programmer pgpa49LI9DQFa.pgp Description: PGP signature
Re: i386 compatibility libstdc++
Steve Langasek [EMAIL PROTECTED] writes: Realistically, are there any C++ apps on the planet that wouldn't choke an i386 to death anyway? groff -- Alan Shutko [EMAIL PROTECTED] - I am the rocks. Looking for a developer in St. Louis? http://web.springies.com/~ats/ I do not fear computers. I fear the lack of them.
Re: i386 compatibility libstdc++
On Friday 25 April 2003 08:06 am, Arnd Bergmann wrote: On Friday 25 April 2003 15:43, Matt Zimmerman wrote: On Fri, Apr 25, 2003 at 01:37:04PM +0200, Emile van Bergen wrote: Hmm... I'd argue for putting the split at either 386 vs 486+ (the latter at least has a math copro and CMPXCHG), or at 386-pentium vs 686+. See the beginning of this thread; the problem is that libstdc++ has drawn a line between 386 and 486. No, the only thing that is enforced is that i386 systems cannot use the i486+ ABI. It is a very possible solution to have use the i386 ABI on any system and the i486+ ABI only on i686+. That will however mean that third party software using libstdc++5 with the i486 ABI won't work will not work on systems with an instruction set older than i686. It's a compromise, but I think it's still better than forcing everyone on the i486 compatibility that is just as obsolete as i386 (i.e. you won't buy any _new_ i486 machines in order to run Debian). I beg to differ. I've purchased a pair of embedded 486/133 machines for use as communication computers running Debian, just in the last couple months. Many others are doing the same with older laptops and even desktops. I would see it as a great shame to lose this support. If we really want to split i386 in 'compatible' and 'fast', the i686 border makes sense because users who care about speed probably bought the machine during the last two years and those should be i686 compatible. Not everyone buys brand new whiz-bang machines. I do not think we should create arbitrary boundaries - this thread began with a boundary that was enforced by code, not just a perception of which machines are newer or faster or more readily available. - Keegan
Re: i386 compatibility libstdc++
On Fri, Apr 25, 2003 at 05:06:00PM +0200, Arnd Bergmann wrote: On Friday 25 April 2003 15:43, Matt Zimmerman wrote: See the beginning of this thread; the problem is that libstdc++ has drawn a line between 386 and 486. No, the only thing that is enforced is that i386 systems cannot use the i486+ ABI. It is a very possible solution to have use the i386 ABI on any system and the i486+ ABI only on i686+. That sounds contrary to what Matthias originally said: - Trying to fix this resulted in libstdc++5 packages built for i386 and ix86, and selecting the atomicity implementation based on target cpu macros. This approach doesn't work, as I learned now. See http://gcc.gnu.org/ml/libstdc++/2003-04/msg00394.html: It's not possible to mix the two implementations. If we really want to split i386 in 'compatible' and 'fast', the i686 border makes sense because users who care about speed probably bought the machine during the last two years and those should be i686 compatible. I agree. -- - mdz
Re: i386 compatibility libstdc++
Le ven 25/04/2003 à 16:06, Craig Dickson a écrit : The slowest machine I ever work with these days is an old Pentium-90 with 32 MB RAM. I won't even put X on that anymore, though it did have X back when it was my only Linux machine. But 486's and Pentiums still make very good TX boxen, so having XFree running on those machines is not superfluous. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: PGP signature
Re: i386 compatibility libstdc++
On Fri, Apr 25, 2003 at 11:55:08AM -0500, Steve Langasek wrote: On Fri, Apr 25, 2003 at 04:36:00PM +0100, Colin Watson wrote: On Fri, Apr 25, 2003 at 09:26:41AM -0500, Steve Langasek wrote: Realistically, are there any C++ apps on the planet that wouldn't choke an i386 to death anyway? groff wouldn't be *that* bad, I don't think ... It had to be pointed out to me that, choking or not, apt is also fairly important to have on the system. :) So perhaps a sub-port consisting of a static libstdc++ library, together with statically-linked versions of groff and apt, would satisfy the needs of i386 users? I haven't worked out an opinion on the general issue yet, but the other two packages in required/important/standard that depend on libstdc++, apart from g++-3.2 via libstdc++5, are dselect and python2.2. -- Colin Watson [EMAIL PROTECTED]
Re: i386 compatibility libstdc++
Steve Langasek [EMAIL PROTECTED] writes: On Fri, Apr 25, 2003 at 08:51:41AM +0200, Matthias Klose wrote: Should Debian further support the i386 target, or make (at least i486) the default for code generation? Asking because I'm unsure how to provide the libstdc++5 package. Realistically, are there any C++ apps on the planet that wouldn't choke an i386 to death anyway? Sure. aspell would be usable (I think). -- I don't know half of you half as well as I should like; and I like less than half of you half as well as you deserve. pgpZTY3Ij5LAy.pgp Description: PGP signature
Re: i386 compatibility libstdc++
On Fri, Apr 25, 2003 at 05:06:00PM +0200, Arnd Bergmann wrote: (i.e. you won't buy any _new_ i486 machines in order to run Debian). Though, buying a new i486 isn't as unusual as you might think. http://www.soekris.com/net4501.htm http://www.soekris.com/net4511.htm http://www.soekris.com/net4521.htm -- - mdz
Re: i386 compatibility libstdc++
On Apr 25, Ben Collins [EMAIL PROTECTED] wrote: I bet someone would rebuild base+some extras using i386 target compiler and make it available, if Debian did that. They would probably serve a few hundred users total, at best. I don't think it would be too much to expect debian-i386 to become a side-project. I fully agree. -- ciao, | Marco | [609 sfGS9NcsyzUUc]
Re: i386 compatibility libstdc++
On 20030425T180852+0200, Emile van Bergen wrote: The problem is STL ... or rather, its abuse. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Taiteellisen ohjelmoinnin ystävien seura Toys - Ohjelmointi on myös taidetta http://www.cc.jyu.fi/yhd/toys/ pgpmtVLKonz7Y.pgp Description: PGP signature
Re: i386 compatibility libstdc++
On Fri, 25 Apr 2003, [ISO-8859-1] Martin v. Löwis wrote: a) Is anybody actually doing this, today? Hell yes. I have 3 of them in the field. Running woody+updates, custom kernel, and absolutely nothing else. b) Do you then have 10MB or 100MB ethernet in that computer? Can you even put a 100MB ethernet card into the computer? Does it have PCI? No PCI (it only became regular in Pentiums, I've seen one or two late-model 486s with PCI, but it's rare). The real question is, do you need anything bigger than a 10Mb card? ADSL and cable both have throughputs much less than 10Mb in general, and that's all your firewall is doing - passing packets between one interface 10Mb, and another which could (theoretically) work at 100Mb, but which you'll never be sending that much through (because of the bottleneck on the other interface). If there is enough userbase for an i386 distribution, I wouldn't mind if an i386 port was maintained separately. However, I really think it would be a good thing if Linux could, in general, assume 486+ (or perhaps even Pentium+). Assuming 486+ I could handle - 386s are becoming rare through component failure. Going for Pentium+ would be a little more radical, though - I know of 8 non-firewall machines all running on 486s (plus a multitude of firewalls). Supporting all of them with home-built security updates would be a problem. The basic problem I see for doing something like upping our minimum spec is the name of the architecture - i386. That implies quite heavily that we do run on 386s. My migration plan (if I had any interest in doing this) would be: * A new architecture, binary-ix86, which would be targetted at something higher than the venerable 386. Widely announce what it's targetted for (perhaps even put it in the name, so binary-i486 or -i586). Get the autobuilders running for this -ix86 architecture for sarge and sid. * After sarge is released, stop running the autobuilders for -i386 on sarge+1 and sid. They'll still have to run for sarge and woody updates, though, as long as they're still around. * For sarge+1 and co, the architecture list will just cease to have -i386 on the list. Calling an architecture -ix86, though, will cause huge problems later on if we ever want to up the base target again. We can retarget the toolchain, but how will we know when all the packages in the architecture has been retargetted? I can only imagine that it will necessitate another new architecture name to retarget all of those packages. Another question - what is the true 586? Pentiums, or those Cyrix/AMD chips which were actually called a 586? IIRC, there were architecture differences between Pentiums and 586s. Oooh, the confusion... Another question, of course, is what does supporting 386s lose us? I've seen this whole flamewar (drop 386 support) before, and what nobody has ever been able to produce is hard numbers saying compiling for a 386 gives an X% performance drop on a Pentium 3, comparsed to code compiled for a (486|Pentium). It's no good optimising your code for a P3 and claiming performance improvement - that's not a realistic test case (since we're not about to start running autobuilders for every class of x86 processor). -- --- #include disclaimer.h Matthew Palmer, Geek In Residence http://ieee.uow.edu.au/~mjp16
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 09:20:33AM +1000, Matthew Palmer wrote: Another question, of course, is what does supporting 386s lose us? I've Binary compatibility with other distributions usability of 3rd-party C++ binaries. That was what started this thread, remember? -- Nick Phillips -- [EMAIL PROTECTED] Abandon the search for Truth; settle for a good fantasy.
Re: i386 compatibility libstdc++
On Fri, Apr 25, 2003 at 05:06:00PM +0200, Arnd Bergmann wrote: If we really want to split i386 in 'compatible' and 'fast', the i686 border makes sense because users who care about speed probably bought the machine during the last two years and those should be i686 compatible. i686 has been common for 6 years now (1997 P2/K6), so its hardly just in the past two years. ;) I agree the split should be at the i686 border assuming this doesn't harm athlon systems. Release Dates (i686+) - Pentium Pro - Nov 1995 Pentium II - Feb 1997 Pentium III - Feb 1999 Pentium IV - Nov 2000 K6 - Apr 1997 Athlon - Aug 1999 Chris
Re: i386 compatibility libstdc++
On Sat, 26 Apr 2003, Nick Phillips wrote: On Sat, Apr 26, 2003 at 09:20:33AM +1000, Matthew Palmer wrote: Another question, of course, is what does supporting 386s lose us? I've Binary compatibility with other distributions usability of 3rd-party C++ binaries. That was what started this thread, remember? I should have been more specific in what I was referring to. The subthread I was replying in was more about a 386 distro in general, and trying to subdue those who would take my message as support for pushing pbuilder-esque sub-architectures into Debian. Perhaps a subject change or similar would have been useful. For the original problem, it surely should be possible to build 386 and 486+ versions of libstdc++ and include both in the distro, with linker magic (or installer magic) to tell the difference? -- --- #include disclaimer.h Matthew Palmer, Geek In Residence http://ieee.uow.edu.au/~mjp16
Re: i386 compatibility libstdc++
On Fri, Apr 25, 2003 at 08:15:05PM -0500, Chris Cheney wrote: | On Fri, Apr 25, 2003 at 05:06:00PM +0200, Arnd Bergmann wrote: | If we really want to split i386 in 'compatible' and 'fast', the i686 border | makes sense because users who care about speed probably bought the machine | during the last two years and those should be i686 compatible. | | i686 has been common for 6 years now (1997 P2/K6), so its hardly just in | the past two years. ;) I agree the split should be at the i686 border | assuming this doesn't harm athlon systems. What about the Via C3? That was introduced not too long ago, runs moderately quickly (~1GHz) with low power consumption, but IIRC doesn't support the i686 instruction set. Cameron.
Re: i386 compatibility libstdc++
Le sam 26/04/2003 à 02:59, Matthew Palmer a écrit : For the original problem, it surely should be possible to build 386 and 486+ versions of libstdc++ and include both in the distro, with linker magic (or installer magic) to tell the difference? That would not be enough. We need specific versions of C++ applications for 386. Of course, only a few should be enough : python, apt, groff... but that is far from an empty list. That's why dropping i386 completely and provide an i386 subset of the distribution seems reasonable. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: PGP signature
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 10:59:19AM +1000, Matthew Palmer wrote: For the original problem, it surely should be possible to build 386 and 486+ versions of libstdc++ and include both in the distro, with linker magic (or installer magic) to tell the difference? We've got /usr/lib/i386 and /usr/lib/i486, certainly ... -- Colin Watson [EMAIL PROTECTED]
Re: i386 compatibility libstdc++
Le sam 26/04/2003 à 03:15, Chris Cheney a écrit : i686 has been common for 6 years now (1997 P2/K6), so its hardly just in the past two years. ;) Err, k6 is not a 686 as to my knowledge. I agree the split should be at the i686 border assuming this doesn't harm athlon systems. This would be a good border, but we would need to provide a much larger subset of packages (if not all the distro) for 386/486/586, while we would only need to provide what can run on a 386 if we set the limit between 386 and 486. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: PGP signature
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 09:36:56AM +0800, Cameron Patrick wrote: What about the Via C3? That was introduced not too long ago, runs moderately quickly (~1GHz) with low power consumption, but IIRC doesn't support the i686 instruction set. The issue with this appears to be a gcc bug with respect to compiling for i686: http://marc.theaimsgroup.com/?l=linux-kernelm=104263370505476w=2 Also, as I understand it the new C3 Nehemiah core now has the cmov instruction. Chris
Re: i386 compatibility libstdc++
On Sat, 26 Apr 2003 02:08, Emile van Bergen wrote: Realistically, are there any C++ apps on the planet that wouldn't choke an i386 to death anyway? There's nothing wrong with the performance of C++ apps. Years ago I did lots of C++ development on a 16MHz 386SX running DOS. The problem is STL and the fact that a lot of C++ programmers tend to forget to conquer while dividing. My logtools package is written in C++ with the STL. It performs well and will be quite useful to anyone who is running Apache for multiple domains on a 386. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
