Hi,
I am surprised with the performances of some 64-bit multi-threaded applications
on my AMD Opteron machine. For most of the applications, the performance of
32-bit version is almost same as the performance of 64-bit version. However, for
a couple of applications, 32-bit versions provide better performance
(running-time is around 76 secs) than 64-bit (running time is around 96 secs).
Could anyone help me to find the reason behind this, please?
$ldd program-64 (64-bit version)
libpthread.so.1 => /lib/64/libpthread.so.1
libstdc++.so.6 => /usr/lib/64/libstdc++.so.6
libm.so.2 => /lib/64/libm.so.2
libgcc_s.so.1 => /usr/lib/64/libgcc_s.so.1
libc.so.1 => /lib/64/libc.so.1
$ ldd program-32 (32-bit version)
libpthread.so.1 => /lib/libpthread.so.1
libstdc++.so.6 => /usr/lib/libstdc++.so.6
libm.so.2 => /lib/libm.so.2
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
libc.so.1 => /lib/libc.so.1
--
This message posted from opensolaris.org
It can be as simple as impact on the cache. 64-bit programs tend to be bigger, and so they have a worse effect on the i-cache. Unless your program does something that can inherently benefit from 64-bit registers, or can take advantage of the richer instruction set that is available to amd64 programs, you probably will see a degradation when running 64-bit programs. That said, I think a great number of programs *do* benefit from the larger registers, and from the richer ISA available to 64-bit programs. - Garrett On Mon, 2010-08-16 at 18:58 -0700, Kishore Kumar Pusukuri wrote:> Hi, > I am surprised with the performances of some 64-bit multi-threaded applications on my AMD Opteron machine. For most of the applications, the performance of 32-bit version is almost same as the performance of 64-bit version. However, for a couple of applications, 32-bit versions provide better performance (running-time is around 76 secs) than 64-bit (running time is around 96 secs). Could anyone help me to find the reason behind this, please? > > > $ldd program-64 (64-bit version) > libpthread.so.1 => /lib/64/libpthread.so.1 > libstdc++.so.6 => /usr/lib/64/libstdc++.so.6 > libm.so.2 => /lib/64/libm.so.2 > libgcc_s.so.1 => /usr/lib/64/libgcc_s.so.1 > libc.so.1 => /lib/64/libc.so.1 > > $ ldd program-32 (32-bit version) > libpthread.so.1 => /lib/libpthread.so.1 > libstdc++.so.6 => /usr/lib/libstdc++.so.6 > libm.so.2 => /lib/libm.so.2 > libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 > libc.so.1 => /lib/libc.so.1
On Mon, Aug 16, 2010 at 21:58, Kishore Kumar Pusukuri <kishore at cs.ucr.edu> wrote:> Hi, > I am surprised with the performances of some 64-bit multi-threaded applications on my AMD Opteron machine. For most of the applications, the performance of 32-bit version is almost same as the performance of 64-bit version. However, for a couple of applications, 32-bit versions provide better performance (running-time is around 76 secs) than 64-bit (running time is around 96 secs). Could anyone help me to find the reason behind this, please? > > > $ldd program-64 ?(64-bit version) > ? ? ? ?libpthread.so.1 => ? ? ? /lib/64/libpthread.so.1 > ? ? ? ?libstdc++.so.6 => ? ? ? ?/usr/lib/64/libstdc++.so.6 > ? ? ? ?libm.so.2 => ? ? /lib/64/libm.so.2 > ? ? ? ?libgcc_s.so.1 => ? ? ? ? /usr/lib/64/libgcc_s.so.1 > ? ? ? ?libc.so.1 => ? ? /lib/64/libc.so.1 > > $ ldd program-32 (32-bit version) > ? ? ? ?libpthread.so.1 => ? ? ? /lib/libpthread.so.1 > ? ? ? ?libstdc++.so.6 => ? ? ? ?/usr/lib/libstdc++.so.6 > ? ? ? ?libm.so.2 => ? ? /lib/libm.so.2 > ? ? ? ?libgcc_s.so.1 => ? ? ? ? /usr/lib/libgcc_s.so.1 > ? ? ? ?libc.so.1 => ? ? /lib/libc.so.1This list discusses the ZFS filesystem. Perhaps you''d be better off posting to perf-discuss or tools-gcc? That said, you need to provide more information. What compiler and flags did you use? What does your program (broadly speaking) do? What did you measure to conclude that it''s slower in 64-bit mode? Will
On 17.08.10 04:17, Will Murnane wrote:> On Mon, Aug 16, 2010 at 21:58, Kishore Kumar Pusukuri > <kishore at cs.ucr.edu> wrote: >> Hi, >> I am surprised with the performances of some 64-bit multi-threaded >> applications on my AMD Opteron machine. For most of the applications, the >> performance of 32-bit version is almost same as the performance of 64-bit >> version. However, for a couple of applications, 32-bit versions provide >> better performance (running-time is around 76 secs) than 64-bit (running >> time is around 96 secs). Could anyone help me to find the reason behind >> this, please?[...]> This list discusses the ZFS filesystem. Perhaps you''d be better off > posting to perf-discuss or tools-gcc? > > That said, you need to provide more information. What compiler and > flags did you use? What does your program (broadly speaking) do? > What did you measure to conclude that it''s slower in 64-bit mode?add to that: what OS are you using? Michael -- michael.schuster at oracle.com http://blogs.sun.com/recursion Recursion, n.: see ''Recursion''
"Garrett D''Amore" <garrett at nexenta.com> wrote:> It can be as simple as impact on the cache. 64-bit programs tend to be > bigger, and so they have a worse effect on the i-cache. > > Unless your program does something that can inherently benefit from > 64-bit registers, or can take advantage of the richer instruction set > that is available to amd64 programs, you probably will see a degradation > when running 64-bit programs. > > That said, I think a great number of programs *do* benefit from the > larger registers, and from the richer ISA available to 64-bit programs.If you have an orthogonal architecture like sparc, a typical 64 bit program is indeed a bit slower than the same program in 32 bit. On Amd64, you have twice as many registers in 64 bit mode and this is the reason for a typical performance gain of ~ 30% for 64 bit applications. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On 08/17/10 09:43 PM, Joerg Schilling wrote:> "Garrett D''Amore"<garrett at nexenta.com> wrote: > > >> It can be as simple as impact on the cache. 64-bit programs tend to be >> bigger, and so they have a worse effect on the i-cache. >> >> Unless your program does something that can inherently benefit from >> 64-bit registers, or can take advantage of the richer instruction set >> that is available to amd64 programs, you probably will see a degradation >> when running 64-bit programs. >> >> That said, I think a great number of programs *do* benefit from the >> larger registers, and from the richer ISA available to 64-bit programs. >> > If you have an orthogonal architecture like sparc, a typical 64 bit program is > indeed a bit slower than the same program in 32 bit. > > On Amd64, you have twice as many registers in 64 bit mode and this is the > reason for a typical performance gain of ~ 30% for 64 bit applications. > >Do you have the data to back that up? Most things I''ve looked at on X64 are slower in 64 bit mode. -- Ian.
> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > bounces at opensolaris.org] On Behalf Of Will Murnane > > > I am surprised with the performances of some 64-bit multi-threaded > > applications on my AMD Opteron machine. For most of the applications, > > the performance of 32-bit version is almost same as the performance of > > 64-bit version. However, for a couple of applications, 32-bit versions > > This list discusses the ZFS filesystem. Perhaps you''d be better off > posting to perf-discuss or tools-gcc? > > That said, you need to provide more information. What compiler and > flags did you use? What does your program (broadly speaking) do? > What did you measure to conclude that it''s slower in 64-bit mode?Not only that, for most things the 32 vs 64bit architectures are expected to perform about the same. The 64bit architecture exists mostly for higher memory addressing bits, not for twice the performance. YMMV.
Ian Collins <ian at ianshome.com> wrote:> > If you have an orthogonal architecture like sparc, a typical 64 bit program is > > indeed a bit slower than the same program in 32 bit. > > > > On Amd64, you have twice as many registers in 64 bit mode and this is the > > reason for a typical performance gain of ~ 30% for 64 bit applications. > > > > > Do you have the data to back that up? Most things I''ve looked at on X64 > are slower in 64 bit mode.Did you test on sparc or amd64? See above... J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On 08/18/10 12:05 AM, Joerg Schilling wrote:> Ian Collins<ian at ianshome.com> wrote: > > >>> If you have an orthogonal architecture like sparc, a typical 64 bit program is >>> indeed a bit slower than the same program in 32 bit. >>> >>> On Amd64, you have twice as many registers in 64 bit mode and this is the >>> reason for a typical performance gain of ~ 30% for 64 bit applications. >>> >>> >>> >> Do you have the data to back that up? Most things I''ve looked at on X64 >> are slower in 64 bit mode. >> > Did you test on sparc or amd64? See above... > >I said x64. Some application benefit from the extended register set and function call ABI, others suffer due to increased sizes impacting the cache. -- Ian.
Ian Collins <ian at ianshome.com> wrote:> On 08/18/10 12:05 AM, Joerg Schilling wrote: > > Ian Collins<ian at ianshome.com> wrote: > > > > > >>> If you have an orthogonal architecture like sparc, a typical 64 bit program is > >>> indeed a bit slower than the same program in 32 bit. > >>> > >>> On Amd64, you have twice as many registers in 64 bit mode and this is the > >>> reason for a typical performance gain of ~ 30% for 64 bit applications. > >>> > >>> > >>> > >> Do you have the data to back that up? Most things I''ve looked at on X64 > >> are slower in 64 bit mode. > >> > > Did you test on sparc or amd64? See above... > > > > > I said x64.You unfortunately did not, this is why I asked.> Some application benefit from the extended register set and function > call ABI, others suffer due to increased sizes impacting the cache.Well, please verify your claims as they do not meet my experience. It may be that you are right in case you don''t compile with optimization. I compile with a high level of optimization and all my applications run at least as fast as in 32 bit mode (as mentioned, this does not apply to sparc). BTW: this applies to Sun Studio. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On 08/18/10 08:40 AM, Joerg Schilling wrote:> Ian Collins<ian at ianshome.com> wrote: > > >> On 08/18/10 12:05 AM, Joerg Schilling wrote: >> >>> Ian Collins<ian at ianshome.com> wrote: >>> >>> >>> >>>>> If you have an orthogonal architecture like sparc, a typical 64 bit program is >>>>> indeed a bit slower than the same program in 32 bit. >>>>> >>>>> On Amd64, you have twice as many registers in 64 bit mode and this is the >>>>> reason for a typical performance gain of ~ 30% for 64 bit applications. >>>>> >>>>> >>>>> >>>>> >>>> Do you have the data to back that up? Most things I''ve looked at on X64 >>>> are slower in 64 bit mode. >>>> >>> Did you test on sparc or amd64? See above... >>> >> I said x64. >> > You unfortunately did not, this is why I asked. > >About half a dozen lines up "Most things I''ve looked at on X64 are slower in 64 bit mode.">> Some application benefit from the extended register set and function >> call ABI, others suffer due to increased sizes impacting the cache. >> > Well, please verify your claims as they do not meet my experience. > >I will.> It may be that you are right in case you don''t compile with optimization. >I do. -- Ian.
On 08/18/10 08:40 AM, Joerg Schilling wrote:> Ian Collins<ian at ianshome.com> wrote: > >> Some application benefit from the extended register set and function >> call ABI, others suffer due to increased sizes impacting the cache. >> > Well, please verify your claims as they do not meet my experience. > > It may be that you are right in case you don''t compile with optimization. > I compile with a high level of optimization and all my applications run at > least as fast as in 32 bit mode (as mentioned, this does not apply to sparc). > BTW: this applies to Sun Studio. > >A quick test with a C++ application I''m working with which does a lot of string and container manipulation shows it runs about 10% slower in 64 bit mode on AMD64 and about the same in 32 or 64 bit on a core i7. Built with -fast. -- Ian.
On 2010-Aug-18 04:40:21 +0800, Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de> wrote:>Ian Collins <ian at ianshome.com> wrote: >> Some application benefit from the extended register set and function >> call ABI, others suffer due to increased sizes impacting the cache. > >Well, please verify your claims as they do not meet my experience.I would agree with Ian that it varies. I have recently been evaluating a number of different SHA256 implementations and have just compared the 32-bit vs 64-bit performance on both x86 (P4 nocona using gcc 4.2.1) and SPARC (US-IVa using Studio12). Comparing the different implementations on each platform, the differences between best and worst varied from 10% to 27% depending on the platform (and the slowest algorithm on x86/64 was equal fastest in the other 3 platforms). Comparing the 32-bit vs 64-bit version of each implementation on each platform, the difference between 32-bit and 64-bit varied from -11% to +13% on SPARC and same to +68% on x86. My interpretation of those results is that you can''t generalise: The only way to determine whether your application is faster in 32-bit or 64-bit more is to test it. And your choice of algorithm is at least as important as whether it''s 32-bit or 64-bit. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100819/b5b97ae1/attachment.bin>
Ian Collins <ian at ianshome.com> wrote:> A quick test with a C++ application I''m working with which does a lot of > string and container manipulation shows it > runs about 10% slower in 64 bit mode on AMD64 and about the same in 32 > or 64 bit on a core i7. Built with -fast.This may be a result of the way the libC you are using was compiled. Try to compare performance tests that only depend on code you did write by your own. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On 08/19/10 08:51 PM, Joerg Schilling wrote:> Ian Collins<ian at ianshome.com> wrote: > > >> A quick test with a C++ application I''m working with which does a lot of >> string and container manipulation shows it >> runs about 10% slower in 64 bit mode on AMD64 and about the same in 32 >> or 64 bit on a core i7. Built with -fast. >> > This may be a result of the way the libC you are using was compiled. > > Try to compare performance tests that only depend on code you did write by your > own. > >Most of the C++ standard library (at least the containers part I''m using) is header only code, so it is mainly code I compile my self. Not using libC is somewhat impractical in real world applications! -- Ian.
> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > bounces at opensolaris.org] On Behalf Of Peter Jeremy > > My interpretation of those results is that you can''t generalise: The > only way to determine whether your application is faster in 32-bit or > 64-bit more is to test it. And your choice of algorithm is at least > as important as whether it''s 32-bit or 64-bit.Not just your choice of algorithm, but architecture. Consider the dramatic architecture difference between Intel and AMD. Though they may have the same instruction set (within reason) the internal circuits to process those instructions are dramatically different, and hence, performance is dramatically different. Intel might be 4x faster at some instruction, while AMD is 4x faster at some other instruction. The same dramatic difference is present for 32 vs 64. As soon as you change modes of your CPU, the architecture of the chip might as well be totally different. If you want to optimize performance, you have to first be able to classify your work load. If you cannot create a job which is truly typical of your work load, all bets are off. Don''t even bother. For general computing, the more you spend, the faster it goes. Only if you have some task which will be repeated for long periods of time ... Then you can benefit by trying this CPU, or that CPU, or this mode, or that mode, or this chipset, or tweaking the compile flags, etc. If you have one task which is faster 32bit, it''s not representative of 32 vs 64 in general. And vice-versa.
On Thu, 2010-08-19 at 21:25 +1200, Ian Collins wrote:> On 08/19/10 08:51 PM, Joerg Schilling wrote: > > Ian Collins<ian at ianshome.com> wrote: > > > > > >> A quick test with a C++ application I''m working with which does a lot of > >> string and container manipulation shows it > >> runs about 10% slower in 64 bit mode on AMD64 and about the same in 32 > >> or 64 bit on a core i7. Built with -fast. > >> > > This may be a result of the way the libC you are using was compiled. > > > > Try to compare performance tests that only depend on code you did write by your > > own. > > > > > Most of the C++ standard library (at least the containers part I''m > using) is header only code, so it is mainly code I compile my self. > > Not using libC is somewhat impractical in real world applications!Not if the program isn''t written in C++! The binary compatibility problems (plus a million other reasons) of C++ make me strongly urge people not to choose C++ as the language for their project unless they are forced to by other constraints. (And then they will have to live with the consequent problems.) -- Garrett
"C. Bergström"
2010-Aug-19 19:13 UTC
[zfs-discuss] [Totally TO] 64-bit vs 32-bit applications
Garrett D''Amore wrote:> On Thu, 2010-08-19 at 21:25 +1200, Ian Collins wrote: > >> On 08/19/10 08:51 PM, Joerg Schilling wrote: >> >>> Ian Collins<ian at ianshome.com> wrote: >>> >>> >>> >>>> A quick test with a C++ application I''m working with which does a lot of >>>> string and container manipulation shows it >>>> runs about 10% slower in 64 bit mode on AMD64 and about the same in 32 >>>> or 64 bit on a core i7. Built with -fast. >>>> >>>> >>> This may be a result of the way the libC you are using was compiled. >>> >>> Try to compare performance tests that only depend on code you did write by your >>> own. >>> >>> >>> >> Most of the C++ standard library (at least the containers part I''m >> using) is header only code, so it is mainly code I compile my self. >> >> Not using libC is somewhat impractical in real world applications! >> > > Not if the program isn''t written in C++! > > The binary compatibility problems (plus a million other reasons) of C++ > make me strongly urge people not to choose C++ as the language for their > project unless they are forced to by other constraints. (And then they > will have to live with the consequent problems.) >I wish you luck in encouraging people to not use C++. While I personally prefer C there is a strong uptake in C++ adoption that is only likely to increase. :) Anyway.. just because you don''t have any solution to replacing libCrun doesn''t mean you have to blacklist the whole language... (keeping in mind that hotspot and a ton of your java/enterprise stack on Solaris is written or dependent on C++) (Why is this being discussed on zfs-discuss) ./C
On 19 Aug 2010, at 19:42, Garrett D''Amore wrote:> On Thu, 2010-08-19 at 21:25 +1200, Ian Collins wrote: >> On 08/19/10 08:51 PM, Joerg Schilling wrote: >>> Ian Collins<ian at ianshome.com> wrote: >>> >>> >>>> A quick test with a C++ application I''m working with which does a >>>> lot of >>>> string and container manipulation shows it >>>> runs about 10% slower in 64 bit mode on AMD64 and about the same >>>> in 32 >>>> or 64 bit on a core i7. Built with -fast. >>>> >>> This may be a result of the way the libC you are using was compiled. >>> >>> Try to compare performance tests that only depend on code you did >>> write by your >>> own. >>> >>> >> Most of the C++ standard library (at least the containers part I''m >> using) is header only code, so it is mainly code I compile my self. >> >> Not using libC is somewhat impractical in real world applications! > > Not if the program isn''t written in C++! > > The binary compatibility problems (plus a million other reasons) of C > ++ > make me strongly urge people not to choose C++ as the language for > their > project unless they are forced to by other constraints. (And then > they > will have to live with the consequent problems.) > > -- Garrett >Out of interest, what language do you recommend? - Daniel
On Thu, 2010-08-19 at 20:14 +0100, Daniel Taylor wrote:> On 19 Aug 2010, at 19:42, Garrett D''Amore wrote: > > Out of interest, what language do you recommend?Depends on the job -- I''m a huge fan of choosing the right tool for the job. I just think C++ tries to be jack of all trades and winds up being master of none. For the work I do, I mostly prefer C. - Garrett
Ian Collins
2010-Aug-19 19:50 UTC
[zfs-discuss] [Totally TO] 64-bit vs 32-bit applications
On 08/20/10 07:13 AM, "C. Bergstr?m" wrote:> > (Why is this being discussed on zfs-discuss) >As a distraction form the endless circular licensing arguments? -- Ian.
On 08/20/10 07:48 AM, Garrett D''Amore wrote:> On Thu, 2010-08-19 at 20:14 +0100, Daniel Taylor wrote: > >> On 19 Aug 2010, at 19:42, Garrett D''Amore wrote: >> >> Out of interest, what language do you recommend? >> > Depends on the job -- I''m a huge fan of choosing the right tool for the > job. I just think C++ tries to be jack of all trades and winds up being > master of none. > >Drifting slightly back on topic, a lot of the ZFS code (and even more driver code) I''ve looked at would be cleaner in C++. As long as a library has a C linkage public interface, there aren''t any compatibility issues. The rest is FUD. -- Ian.
Garrett D''Amore wrote:> On Thu, 2010-08-19 at 20:14 +0100, Daniel Taylor wrote: > >> On 19 Aug 2010, at 19:42, Garrett D''Amore wrote: >> >> Out of interest, what language do you recommend? >> > > Depends on the job -- I''m a huge fan of choosing the right tool for the > job. I just think C++ tries to be jack of all trades and winds up being > master of none. > > For the work I do, I mostly prefer C. >(My perspective is biased, but...) End users from my experience and perspective pick a language that offers them a balance between easy to use programming model and performance. C++ is a language standard and not a "jack of all trades"... It''s like saying don''t use ZFS because it''s trying to be "jack of all trades" and used across many different industries and applications (successfully)
Ian Collins wrote:> On 08/20/10 07:48 AM, Garrett D''Amore wrote: >> On Thu, 2010-08-19 at 20:14 +0100, Daniel Taylor wrote: >> >>> On 19 Aug 2010, at 19:42, Garrett D''Amore wrote: >>> >>> Out of interest, what language do you recommend? >>> >> Depends on the job -- I''m a huge fan of choosing the right tool for the >> job. I just think C++ tries to be jack of all trades and winds up being >> master of none. >> >> > Drifting slightly back on topic, a lot of the ZFS code (and even more > driver code) I''ve looked at would be cleaner in C++. As long as a > library has a C linkage public interface, there aren''t any > compatibility issues. The rest is FUD.I believe his root concern is/was that libCrun is closed source and a drop-in replacement won''t be easily possible until the compiler switches over to using the IA64 C++ ABI. (Garrett please feel to correct me if my assumption is wrong)
On Fri, 2010-08-20 at 07:58 +1200, Ian Collins wrote:> On 08/20/10 07:48 AM, Garrett D''Amore wrote: > > On Thu, 2010-08-19 at 20:14 +0100, Daniel Taylor wrote: > > > >> On 19 Aug 2010, at 19:42, Garrett D''Amore wrote: > >> > >> Out of interest, what language do you recommend? > >> > > Depends on the job -- I''m a huge fan of choosing the right tool for the > > job. I just think C++ tries to be jack of all trades and winds up being > > master of none. > > > > > Drifting slightly back on topic, a lot of the ZFS code (and even more > driver code) I''ve looked at would be cleaner in C++. As long as a > library has a C linkage public interface, there aren''t any compatibility > issues. The rest is FUD.There is no common C++ ABI. So you get into compatibility concerns between code built with different compilers (like Studio vs. g++). Fail. There are many many things to dislike about C++ -- you *can* write good clean code in C++, but almost none of the C++ code I''ve seen fits that description. The various side effects, and unexpected memory explosion that occurs with the "favored" C++ constructs tends to make C++ completely unsuitable for use in a kernel. I still have the scars from when Linus tried to experiment with a Linux kernel in C++. :-) The effort was *very* short lived. Granted C++ has changed a lot since then, but I think the ways it has changed make it even more unsuitable for kernel/embedded work. - Garrett
On Fri, 2010-08-20 at 03:26 +0700, "C. Bergstr?m" wrote:> Ian Collins wrote: > > On 08/20/10 07:48 AM, Garrett D''Amore wrote: > >> On Thu, 2010-08-19 at 20:14 +0100, Daniel Taylor wrote: > >> > >>> On 19 Aug 2010, at 19:42, Garrett D''Amore wrote: > >>> > >>> Out of interest, what language do you recommend? > >>> > >> Depends on the job -- I''m a huge fan of choosing the right tool for the > >> job. I just think C++ tries to be jack of all trades and winds up being > >> master of none. > >> > >> > > Drifting slightly back on topic, a lot of the ZFS code (and even more > > driver code) I''ve looked at would be cleaner in C++. As long as a > > library has a C linkage public interface, there aren''t any > > compatibility issues. The rest is FUD. > I believe his root concern is/was that libCrun is closed source and a > drop-in replacement won''t be easily possible until the compiler switches > over to using the IA64 C++ ABI. (Garrett please feel to correct me if > my assumption is wrong)That is a major concern. But the problem is also that the ABIs created by different compilers vary. You can''t mix g++ and studio generated code, for example. That''s not FUD, its technical fact. -- Garrett
Garrett D''Amore wrote:> On Fri, 2010-08-20 at 07:58 +1200, Ian Collins wrote: > >> On 08/20/10 07:48 AM, Garrett D''Amore wrote: >> >>> On Thu, 2010-08-19 at 20:14 +0100, Daniel Taylor wrote: >>> >>> >>>> On 19 Aug 2010, at 19:42, Garrett D''Amore wrote: >>>> >>>> Out of interest, what language do you recommend? >>>> >>>> >>> Depends on the job -- I''m a huge fan of choosing the right tool for the >>> job. I just think C++ tries to be jack of all trades and winds up being >>> master of none. >>> >>> >>> >> Drifting slightly back on topic, a lot of the ZFS code (and even more >> driver code) I''ve looked at would be cleaner in C++. As long as a >> library has a C linkage public interface, there aren''t any compatibility >> issues. The rest is FUD. >> > > There is no common C++ ABI.Not true - http://www.codesourcery.com/public/cxx-abi/abi.html> So you get into compatibility concerns > between code built with different compilers (like Studio vs. g++). >SS is homebrew now, but at some point in the future will switch over to the Itanium C++ ABI. On linux how many compiler vendors conform to this ABI? I would say there''s enough to call it a defacto standard. Please realize that with the exception of Windows it''s available and commonly used almost everywhere...> Fail. > > There are many many things to dislike about C++ -- you *can* write good > clean code in C++, but almost none of the C++ code I''ve seen fits that > description. >I could say the same for java, php and lots of other languages.. While I don''t argue if your view is correct or accurate it''s just your opinion biased by your daily requirements (as a kernel developer)> The various side effects, and unexpected memory explosion that occurs > with the "favored" C++ constructs tends to make C++ completely > unsuitable for use in a kernel. > > I still have the scars from when Linus tried to experiment with a Linux > kernel in C++. :-) The effort was *very* short lived. Granted C++ has > changed a lot since then, but I think the ways it has changed make it > even more unsuitable for kernel/embedded work. >Ok so C++ is generally suitable for everything outside of kernel and embedded work ;)
On Thu, 19 Aug 2010, Garrett D''Amore wrote:> > There are many many things to dislike about C++ -- you *can* write good > clean code in C++, but almost none of the C++ code I''ve seen fits that > description. > > The various side effects, and unexpected memory explosion that occurs > with the "favored" C++ constructs tends to make C++ completely > unsuitable for use in a kernel.Since 1996, all of my professional programming work (for products) has been done in C++. Most of my open source work has been done in C. There should be little doubt that C++ is a much better implementation/design language than C, however, it does suffer from the interoperability concerns (and cross-compiler portability concerns) that Garrett mentions. I have not encountered issues with excessive memory consumption or slow execution. There are plenty of people who don''t know how to program in C++ or other object oriented languages. Most of these people should not be programming at all. Zfs could have been implemented in C++, but it would not be as friendly in a kernel which is already implemented in C. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Garrett D''Amore wrote:> That is a major concern. But the problem is also that the ABIs created > by different compilers vary. You can''t mix g++ and studio generated > code, for example. That''s not FUD, its technical fact. >Not today, but it''s my understanding this will be possible in the future.. (At least in theory)
On 08/20/10 08:35 AM, Garrett D''Amore wrote:> On Fri, 2010-08-20 at 03:26 +0700, "C. Bergstr?m" wrote: > >> Ian Collins wrote: >> >>> On 08/20/10 07:48 AM, Garrett D''Amore wrote: >>> >>>> On Thu, 2010-08-19 at 20:14 +0100, Daniel Taylor wrote: >>>> >>>> >>>>> On 19 Aug 2010, at 19:42, Garrett D''Amore wrote: >>>>> >>>>> Out of interest, what language do you recommend? >>>>> >>>>> >>>> Depends on the job -- I''m a huge fan of choosing the right tool for the >>>> job. I just think C++ tries to be jack of all trades and winds up being >>>> master of none. >>>> >>>> >>>> >>> Drifting slightly back on topic, a lot of the ZFS code (and even more >>> driver code) I''ve looked at would be cleaner in C++. As long as a >>> library has a C linkage public interface, there aren''t any >>> compatibility issues. The rest is FUD. >>> >> I believe his root concern is/was that libCrun is closed source and a >> drop-in replacement won''t be easily possible until the compiler switches >> over to using the IA64 C++ ABI. (Garrett please feel to correct me if >> my assumption is wrong) >> > That is a major concern. But the problem is also that the ABIs created > by different compilers vary. You can''t mix g++ and studio generated > code, for example. That''s not FUD, its technical fact. > >That depends on the definition of "mix". Provided the interfaces comply with the extern "C" rules, you''re OK. It''s not there yet, but one of the stated goals of the Studio product is ABI compatibility with gcc. -- Ian.
"Garrett D''Amore" <garrett at nexenta.com> wrote:> There is no common C++ ABI. So you get into compatibility concerns > between code built with different compilers (like Studio vs. g++). > Fail. >The interesting thing is: Sun Studio on Linux is able to interoperate with g++ J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On Thu, 2010-08-19 at 15:48 -0500, Bob Friesenhahn wrote:> On Thu, 19 Aug 2010, Garrett D''Amore wrote:> > Since 1996, all of my professional programming work (for products) has > been done in C++. Most of my open source work has been done in C. > There should be little doubt that C++ is a much better > implementation/design language than C, however, it does suffer from > the interoperability concerns (and cross-compiler portability > concerns) that Garrett mentions. I have not encountered issues with > excessive memory consumption or slow execution.My most recent experience with excessive memory consumption came when trying to take a certain chunk of C++ code from a third party vendor, and insert it into a tiny kernel. The code basically added encryption, and should not have been huge. But it doubled the memory footprint of the project. (The rest of the code was the Sun Ray firmware.) It was significantly challenging to prune enough space to make the code fit in this embedded environment. The problems largely come, I think, from the standard C++ library. I know that it is *possible* to write C++ code that doesn''t do this -- but then you''re basically writing C code using the C++ compiler. :-)> > There are plenty of people who don''t know how to program in C++ or > other object oriented languages. Most of these people should not be > programming at all.Yes. The problem is that C++ makes it too easy, IMO, to write code that is completely illegible even when they don''t mean to. C can do this to, but at least for the most part the language is explicit. Use the + operator generally doesn''t cause memory allocations to occur, for example.> > Zfs could have been implemented in C++, but it would not be as > friendly in a kernel which is already implemented in C.Which includes all of the kernels which currently use it. -- Garrett
On 08/20/10 08:30 AM, Garrett D''Amore wrote:> On Fri, 2010-08-20 at 07:58 +1200, Ian Collins wrote: > >> On 08/20/10 07:48 AM, Garrett D''Amore wrote: >> >>> On Thu, 2010-08-19 at 20:14 +0100, Daniel Taylor wrote: >>> >>> >>>> On 19 Aug 2010, at 19:42, Garrett D''Amore wrote: >>>> >>>> Out of interest, what language do you recommend? >>>> >>>> >>> Depends on the job -- I''m a huge fan of choosing the right tool for the >>> job. I just think C++ tries to be jack of all trades and winds up being >>> master of none. >>> >>> >>> >> Drifting slightly back on topic, a lot of the ZFS code (and even more >> driver code) I''ve looked at would be cleaner in C++. As long as a >> library has a C linkage public interface, there aren''t any compatibility >> issues. The rest is FUD. >> > There is no common C++ ABI. So you get into compatibility concerns > between code built with different compilers (like Studio vs. g++). > Fail. >Which is why we have extern "C". Just about any Solaris driver, library or kernel module could be implemented in C++ behind the C compatibility layer and no one would notice.> There are many many things to dislike about C++ -- you *can* write good > clean code in C++, but almost none of the C++ code I''ve seen fits that > description. > >You should try some of mine!> The various side effects, and unexpected memory explosion that occurs > with the "favored" C++ constructs tends to make C++ completely > unsuitable for use in a kernel. > >Those are a QoP (Quality of Programmer) issues. Competent programmers do not fall into those traps. Novices in any language will try and use as much as they can because it''s all new. Those of us with older heads know to select the appropriate features for the job in hand. Drivers and kernel modules are a good example; in that world you have to live without the runtime library (which is dynamic only). So you are effectively just using C++ as a superset of C with all the benefits that offers. I recently coached a DSP team on using C++. All they wanted was a "better C", nothing flash. The big selling point to that team (and others I have worked with) was automatic resource management, the one C++ feature C can''t emulate. This is one tool that leads to cleaner, leak free, code. -- Ian.
On Fri, 2010-08-20 at 09:23 +1200, Ian Collins wrote:> >> > > There is no common C++ ABI. So you get into compatibility concerns > > between code built with different compilers (like Studio vs. g++). > > Fail. > > > > Which is why we have extern "C". Just about any Solaris driver, library > or kernel module could be implemented in C++ behind the C compatibility > layer and no one would notice.As long as they don''t depend on other features, like the C++ standard library. Once they consume any external C++ interfaces, you''re dead. Because you can''t mix g++ standard libraries with those from Studio. -- Garrett
On Fri, Aug 20, 2010 at 09:23:56AM +1200, Ian Collins wrote:> On 08/20/10 08:30 AM, Garrett D''Amore wrote: > >There is no common C++ ABI. So you get into compatibility concerns > >between code built with different compilers (like Studio vs. g++). > >Fail. > > Which is why we have extern "C". Just about any Solaris driver, > library or kernel module could be implemented in C++ behind the C > compatibility layer and no one would notice.Any driver C++ code would still need a C++ run-time. Either you must statically link it in, or you''ll have a problem with multiple drivers using different C++ run-times. If you statically link in the run-time, then you''re bloating the text of the kernel. If you''re not then you have a problem. C++ is bad because of its ABI issues, really. Nico --
On 08/20/10 09:26 AM, Garrett D''Amore wrote:> On Fri, 2010-08-20 at 09:23 +1200, Ian Collins wrote: > >>> There is no common C++ ABI. So you get into compatibility concerns >>> between code built with different compilers (like Studio vs. g++). >>> Fail. >>> >> Which is why we have extern "C". Just about any Solaris driver, library >> or kernel module could be implemented in C++ behind the C compatibility >> layer and no one would notice. >> > As long as they don''t depend on other features, like the C++ standard > library. Once they consume any external C++ interfaces, you''re dead. >Which is what I said further down... Just adding resource management to C is a huge win. Anything that removes an excuse to use goto has to be applauded! -- Ian.
On 08/20/10 09:33 AM, Nicolas Williams wrote:> On Fri, Aug 20, 2010 at 09:23:56AM +1200, Ian Collins wrote: > >> On 08/20/10 08:30 AM, Garrett D''Amore wrote: >> >>> There is no common C++ ABI. So you get into compatibility concerns >>> between code built with different compilers (like Studio vs. g++). >>> Fail. >>> >> Which is why we have extern "C". Just about any Solaris driver, >> library or kernel module could be implemented in C++ behind the C >> compatibility layer and no one would notice. >> > Any driver C++ code would still need a C++ run-time. Either you must > statically link it in, or you''ll have a problem with multiple drivers > using different C++ run-times. If you statically link in the run-time, > then you''re bloating the text of the kernel. If you''re not then you > have a problem. C++ is bad because of its ABI issues, really. > >You snipped the bit where I said "Drivers and kernel modules are a good example; in that world you have to live without the runtime library (which is dynamic only). So you are effectively just using C++ as a superset of C with all the benefits that offers." So you basically loose the C++ specific parts of the standard library and exceptions. But you still have the built in features of the language. -- Ian.
On Fri, Aug 20, 2010 at 09:38:51AM +1200, Ian Collins wrote:> On 08/20/10 09:33 AM, Nicolas Williams wrote: > >Any driver C++ code would still need a C++ run-time. Either you must > >statically link it in, or you''ll have a problem with multiple drivers > >using different C++ run-times. If you statically link in the run-time, > >then you''re bloating the text of the kernel. If you''re not then you > >have a problem. C++ is bad because of its ABI issues, really. > > > You snipped the bit where I said > > "Drivers and kernel modules are a good example; in that world you > have to live without the runtime library (which is dynamic only). > So you are effectively just using C++ as a superset of C with all > the benefits that offers." > > So you basically loose the C++ specific parts of the standard > library and exceptions. But you still have the built in features of > the language.I''m not sure it''s that easy to avoid the C++ run-time when you''re coding. And anyways, the temptation to build classes that can be used elsewhere becomes rather strong. IMO C++ in the kernel is asking for trouble. And C++ in user-land? Same thing: you''ll end up wanting to turn parts of your application into libraries, and then some other developer will want to use those in their C++ app, and then you run into the ABI issues all over again. Nico --
On 08/20/10 09:48 AM, Nicolas Williams wrote:> On Fri, Aug 20, 2010 at 09:38:51AM +1200, Ian Collins wrote: > >> On 08/20/10 09:33 AM, Nicolas Williams wrote: >> >>> Any driver C++ code would still need a C++ run-time. Either you must >>> statically link it in, or you''ll have a problem with multiple drivers >>> using different C++ run-times. If you statically link in the run-time, >>> then you''re bloating the text of the kernel. If you''re not then you >>> have a problem. C++ is bad because of its ABI issues, really. >>> >>> >> You snipped the bit where I said >> >> "Drivers and kernel modules are a good example; in that world you >> have to live without the runtime library (which is dynamic only). >> So you are effectively just using C++ as a superset of C with all >> the benefits that offers." >> >> So you basically loose the C++ specific parts of the standard >> library and exceptions. But you still have the built in features of >> the language. >> > I''m not sure it''s that easy to avoid the C++ run-time when you''re > coding.Like anything else in software development, set guidelines and follow them. The system is the ultimate arbitrator; you soon learn when you module refuses to load!> And anyways, the temptation to build classes that can be used > elsewhere becomes rather strong. IMO C++ in the kernel is asking for > trouble. And C++ in user-land? Same thing: you''ll end up wanting to > turn parts of your application into libraries, and then some other > developer will want to use those in their C++ app, and then you run into > the ABI issues all over again. >There are a couple of simple solutions to that. Either make library code header only (which is most common for template based code) or provide CC and gcc libraries, just like we have 32 and 64 bit versions of other system libraries. Or just stick to one compiler, like Solaris did before the big gcc build project kicked off. -- Ian.
On Fri, Aug 20, 2010 at 10:17:38AM +1200, Ian Collins wrote:> On 08/20/10 09:48 AM, Nicolas Williams wrote: > >And anyways, the temptation to build classes that can be used > >elsewhere becomes rather strong. IMO C++ in the kernel is asking for > >trouble. And C++ in user-land? Same thing: you''ll end up wanting to > >turn parts of your application into libraries, and then some other > >developer will want to use those in their C++ app, and then you run into > >the ABI issues all over again. > > There are a couple of simple solutions to that. Either make library > code header only (which is most common for template based code) or > provide CC and gcc libraries, just like we have 32 and 64 bit > versions of other system libraries. Or just stick to one compiler, > like Solaris did before the big gcc build project kicked off.Or wait for a standard ABI to be formulated and widely adopted. Or don''t use C++. Use Java or a JVM-hosted language. Use Python. Use C. Use C#. Use whatever. Anything, anything other than C++. But more than anything: we don''t need a language flame war on a ZFS list.