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'
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
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 st
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++)
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 abou
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". Ju
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, li
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 lan
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 mu
"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.
>
The interesting thing is: Sun Studio on Linux is able to interoperate with g++
Jörg
--
EMail:jo...@schily.isdn.cs.tu-b
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
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
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++ co
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
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 yo
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?
> >>
> > De
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 fo
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 j
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
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 u
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 wrote:
A quick test with a C++ application I'm working with which does a
lot of
string and container manipulation shows it
runs
On Thu, 2010-08-19 at 21:25 +1200, Ian Collins wrote:
> On 08/19/10 08:51 PM, Joerg Schilling wrote:
> > Ian Collins 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
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@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 y
On 08/19/10 08:51 PM, Joerg Schilling wrote:
Ian Collins 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 -fas
Ian Collins 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 li
On 2010-Aug-18 04:40:21 +0800, Joerg Schilling
wrote:
>Ian Collins 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
On 08/18/10 08:40 AM, Joerg Schilling wrote:
Ian Collins 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
On 08/18/10 08:40 AM, Joerg Schilling wrote:
Ian Collins wrote:
On 08/18/10 12:05 AM, Joerg Schilling wrote:
Ian Collins 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,
Ian Collins wrote:
> On 08/18/10 12:05 AM, Joerg Schilling wrote:
> > Ian Collins 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
On 08/18/10 12:05 AM, Joerg Schilling wrote:
Ian Collins 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 typica
Ian Collins 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%
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@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 v
On 08/17/10 09:43 PM, Joerg Schilling wrote:
"Garrett D'Amore" 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 ca
"Garrett D'Amore" 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
On 17.08.10 04:17, Will Murnane wrote:
On Mon, Aug 16, 2010 at 21:58, 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 t
On Mon, Aug 16, 2010 at 21:58, 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
> versi
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 progr
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 bette
38 matches
Mail list logo
