The first and foremost question I must ask is what platforms that don't
support C++ 11 are you prepared to write off? It's possible, I suppose, to
write conditional code that supports for C++ 11 and legaccy C++, but from
much experience, that's the formula for a disaster. Code must debugged in
al enviroments and platforms, bring to mind the old wag about Java applets
"write once, debug everywhere."
I've used C++ heavily for well over a decade and a half. I have always
found it an overblown language with too many features and not enough deep
thought. But writing C++ with Java semantic and conventions works well.
In my ever humble opinion as a language designer, the Java guys were head
and shoulders smarter than the C++ guys.
The C++ 11 standard is approximately 1/3 adoption of Java features, 1/3
fixes to earlier bad design, and 1/3 semi-newish stuff. The only reallly
interestinng feature is compiler specified thread speciific data. If the
compile has the native wit (sic) to use an otherwise unuseable register to
point to thread specific data, this is a big win for multi-threaded code.
Some compilers already have this functionality as proprietary extensions,
so while nothing new, it should be celebrated.
Other than wiping out various platforms, there are a number of significant
down sides. The biggest, to my mind, is an opportunity for zealots to
further degrade the code base to use as many new features as possible.
This has been a major problem in the past when "const correctness" disease
overwhelmed a number of developers who pretty much trashed the code base
with unnecessary, inappropriate, and just plain wrong const pointers
requiring an near infinite number of casts to undo the ill-consider const
points, rendering a once type save code base horribly unsafe, all done in
the name of progress.
There are some benefits to C++ 11, but most are relatively minor and mostly
undue really base restrictions of POD structures. But all know compilers
have options to turn that crap off, so nothing is really gained.
Among language designers, it is well understood that macros exist to paper
over flaws in language design. Java, to the designer's credit, has no
macros and no preprocessor. The Java language, in short, is intended to
stand on its own without the crutch of macros. Template are, in essence,
macros. There does need to make provision for procedures with soft types.
Java builds this into a language extension. C++ templates, however, are a
layer on the C++ language, and enable all sorts of unmaintainable abuse.
Aggregate classes, fine. Other uses, not so fine.
I would advise Firebird to wait three or four years to build a dependency
on a language varient that is little more than a fix on previous mistakes
avoid a future overhaul to fix this C++ round of ill-considered mistakes.
Having serviced on industry standards committees, I have found that the
representatives tend more to be people that everyone else wants out of the
office (telephone sanitizers, in short) than the best and the brightest.
On Friday, March 20, 2015, Egor Pugin <egor.pu...@gmail.com> wrote:
> Hi,
>
> What about just "The power of C++11 in Firebird" ?
>
> On 20 March 2015 at 23:44, James Starkey <j...@jimstarkey.net
> <javascript:;>> wrote:
> > I think it would be extremely difficult to implement both fine grain
> > multi-threading and co-processor exploitation in a shared meta-data
> > implementation. If Firebird were rearchitected so that each connection
> had
> > a dedicated metadata cache (and the caches with a mechanism to propagate
> > metadata changes to all threads, then it would probably be feasible but
> > would also incur all sorts of additional overheads.
> >
> > Also, keep in mind that if you use a library that makes coprocessor usage
> > transparent, then in the 99.99% of installations that don't have
> > coprocessors installed, you're adding major overhead with no possible
> gain.
> >
> > There's an important lesson to be learned from the Sun 350 Workstation.
> The
> > 350 was designed to use a bit-blit chip from Carver Meade's Silicon
> > Compilers. The chip worked as spec'd, but when they plugged it in, the
> > graphics went slower. Turned out that although the chip was great for
> large
> > transfers, most operations were small, and the set up cost for the
> operation
> > was greater than operation in software. So they added a test to
> distinguish
> > between small and large operations. Then the graphics went even slower
> as
> > the more common short operations became even slower with the addition of
> the
> > test.
> >
> > I'm deeply cynical about hardware acceleration for database systems.
> Dozens
> > and dozens have been tried and nothing has succeeded. There are at least
> > two or three dead companies that tried to accelerate MySQL. I'm not
> saying
> > it can't be done, just that nobody has ever succeeded on relational
> database
> > type workloads.
> >
> > Personally, I consider it folly. It is some much better to use large
> > numbers of very cheap commodity servers than a single very expensive (and
> > rare) systems. NuoDB running on a bunch of cheap processors will blow
> the
> > doors off a single fast system with high end coprocessors for throughput.
> > The last numbers I heard was something like 1.5 million transactions per
> > second running on a hundred servers. Your milage may vary.
> >
> > I think it would be vastly better for Firebird to address operating
> across
> > cheap commodity servers than to optimize for exotic -- and
> hyper-expensive
> > -- servers.
> >
> > On Friday, March 20, 2015, Leyne, Sean <s...@broadviewsoftware.com
> <javascript:;>> wrote:
> >>
> >> Jim,
> >>
> >> > The problem with specialized processors is that they are a scarce
> >> > resource that must be managed rather than shared. They're just dandy
> >> > when a server has a single specialized load, but on a server with
> >> > multiple clients, one guy gets the specialized processor and everyone
> >> > one else waits.
> >> >
> >> > The best way for Firebird to do parallism is to move towards fine
> >> > grain multi- threading so at least all available processors can keep
> >> > busy doing useful work. Trying to accelerate a single operation with
> >> > non-shared hardware is almost always a net loss.
> >>
> >> To my way of thinking/understanding the current OpenCL/GPU/PHI solutions
> >> can be used as a shared resource.
> >>
> >> To be clear, I am proposing that the development focus should be on
> >> refactoring the existing code with the view of improving multi-threading
> >> support, first, and then parallelism -- thru libraries like the Intel
> C++
> >> Compiler or Intel Parallel Studio which can automatically detect and use
> >> available hardware (CPU/threads, MPI, GPU or coprocessor) to the
> greatest
> >> extent possible.
> >>
> >> Granted for some of the solutions, some resource management/queuing may
> be
> >> required, but the overall performance payoff could be worth it.
> >>
> >> In the case of the PHI, having up to 61* "helper" processors which could
> >> be responsible for performing sorting/grouping for *any* running query
> (so a
> >> shared resource) would provide significant benefit. In the case of the
> PHI,
> >> each processor is a full x86 instance, so unlike GPU based solutions no
> >> specialized instructions set would be required.
> >>
> >> * 57 to 61 cores (@1.053 to 1.238Ghz) per PHI card, a server could have
> >> several cards -- up to 8 cards per server.
> >>
> >>
> >> > You might remember that the original DEC JRD was the core for what was
> >> > eventually be the DEC database machine. We had people on specialized
> >> > hardware and specialized microcode.
> >>
> >> Granted I am now an old man with a 20yr old son, but I wasn't around in
> >> the Neolithic era! ;-]
> >>
> >>
> >> > The Falcon group at MySQL had a long meeting with the Intel
> >> > parallelization tool group.
> >>
> >> My I ask, when were those discussions?
> >>
> >> Was the XEON PHI discussed?
> >>
> >>
> >> > At the end of the day, everyone was in agreement that with more
> >> > processes than cores, fine grain multi-threading using user mode
> >> > interlocked instructions for thread synchronization was by far the
> >> > best solution.
> >>
> >> Again, there are some operations (ie. Sorting/merging/grouping) where
> >> interlocked instructions are not necessary.
> >>
> >>
> >> Sean
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Dive into the World of Parallel Programming The Go Parallel Website,
> >> sponsored
> >> by Intel and developed in partnership with Slashdot Media, is your hub
> for
> >> all
> >> things parallel software development, from weekly thought leadership
> blogs
> >> to
> >> news, videos, case studies, tutorials and more. Take a look and join the
> >> conversation now. http://goparallel.sourceforge.net/
> >> Firebird-Devel mailing list, web interface at
> >> https://lists.sourceforge.net/lists/listinfo/firebird-devel
> >
> >
> >
> > --
> > Jim Starkey
> >
> >
> ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming The Go Parallel Website,
> > sponsored
> > by Intel and developed in partnership with Slashdot Media, is your hub
> for
> > all
> > things parallel software development, from weekly thought leadership
> blogs
> > to
> > news, videos, case studies, tutorials and more. Take a look and join the
> > conversation now. http://goparallel.sourceforge.net/
> > Firebird-Devel mailing list, web interface at
> > https://lists.sourceforge.net/lists/listinfo/firebird-devel
> >
>
>
>
> --
> Egor Pugin
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>
--
Jim Starkey
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
