View mode: basic / threaded / horizontal-split · Log in · Help
June 07, 2012
C++Now! 2012 slides
The slide packs of the conference C++Now! 2012 are available:
https://github.com/boostcon/cppnow_presentations_2012

Some of those slides packs seems too much large for the GitHub 
blob serving interface. To solve this problem download them all 
from as zip here (large amount of stuff):
https://github.com/boostcon/cppnow_presentations_2012/downloads

Among those many (sometimes large) slides packs there is some 
good stuff. I think some of that stuff is interesting for D 
programmers too. I have chosen four of them.

----------------------------

"50 Boost C++ Libraries in 180 minutes", by Boris Schaling:

Among the Libraries shown, in Phobos I'd like the 12 libraries:

- Boost.Pool Memory management with an allocator based on a 
singleton.
- Boost.Multiindex Create new containers which provide multiple 
interfaces to lookup items.
- Boost.Bimap A ready-to-use container based on Boost.Multiindex 
with exactly two interfaces.
- Boost.CircularBuffer A fixed-size container which overwrites 
items if you keep on inserting more (I'd like a dynamic version 
too of this).
- Boost.DynamicBitset Works exactly like std::bitset except that 
the size can be set (and modified) at run-time (in Phobos I'd 
like a in-place-allocated fixed-size one too).
- Boost.Flyweight Flyweight pattern: Sharing common data between 
objects to minimize memory usage.
- Boost.Accumulators Containers which calculate new results 
whenever a new value is pushed into them.
- Boost.Rational Use exact representations of rational numbers 
like 1/3 in C++.
- Boost.Graph A library to solve problems like finding the 
shortest route between two subway stations.
- Boost.Conversion Three cast operators for numbers and 
polymorphic types.
- Boost.MinMax Find the minimum and maximum of two or multiple 
values with one function call.
- Boost.Hash Classes and functions to return hash values and to 
build your own for user-defined types.

----------------------------

"Metaprogramming Applied to Numerical Problems - A Generic 
Implementation of Runge-Kutta Algorithms", by Mario Mulansky and 
Karsten Ahnert: this should be not hard to do in D, with less and 
simpler code.

----------------------------

"More Useful Computations in the Same Duration: Optimizing 
Embedded Hard Real-Time Code in C++", by Scott Schurr:

Page 46: #pragma no_alias Are we going to need something like 
that (or "restrict") in D too?


Page 55, Managing Code Bloat:

Maybe D should offer a built-in solution for this common C++ 
coding pattern:

Class TCB_impl {
    template<int chan> friend class TCB;
    inline void status(int chan) { ... }
    void source(int chan, int st) { ... }
};

template <int chan>
class TCB {
public:
    inline void status() { impl_.status(chan); }
    inline void source(int st) { impl_.start(chan, st); }
private:
    TCB_impl impl_;
};


Some time ago I suggested the attribute @templated(). If inside 
its () there are no variable names then that function/attribute 
is not templated, so it's like the functions/attributes of 
TCB_impl:


class TCB(int chan) {
public:
    void status() { status_impl(chan); }
    @templated() void status_impl(int chan) { ... }

    void source(int st) { source_impl(chan, st); }
    @templated() void source_impl(int chan, int st) { ... }
}


But maybe something better is possible:

class TCB(int chan) {
    @templated() immutable mchan = chan;
public:
    this() { this.mchan = chan; }
    @templated() void status() { /*uses mchan*/... }
    @templated() void source(int st) { /*uses mchan*/... }
}

----------------------------

"Now What?" by Sean Parent (Adobe).

Slide 29 (page 18), "Desktop Compute Power" shows that nowdays 
for some tasks GPU and vectorized code are much faster than 
regular sequential C++ code.


Slides 36 and 38:
That typical object oriented paradigms of using shared references 
to objects breaks down in a massively parallel environment
* Sharing implies either single threaded
* Or synchronization
To utilize the hardware we need to move towards functional, 
declarative, reactive, and value semantic programming No raw loops


Slide 40 (page 25) adds to slide 29: "Without addressing 
vectorization, GPGPU, and scalable parallelismW standard C++ is 
just a scripting system to get to the other 99% of the machine 
through other languages and libraries. Do we need such a complex 
scripting system?"

The same question is valid for D. It seems important.

Bye,
bearophile
June 07, 2012
Re: C++Now! 2012 slides
On 06/07/12 18:04, bearophile wrote:
> Page 46: #pragma no_alias Are we going to need something like that (or "restrict") in D too?

"restrict" functionality - yes, but it's probably better done the other way around -
restrict as default and "alias" when necessary. Reusing the keyword could work too,
if template parameters is the only thing that can clash.

artur
June 07, 2012
Re: C++Now! 2012 slides
On Thursday, 7 June 2012 at 17:17:07 UTC, Artur Skawina wrote:
> On 06/07/12 18:04, bearophile wrote:
>> Page 46: #pragma no_alias Are we going to need something like 
>> that (or "restrict") in D too?
>
> "restrict" functionality - yes, but it's probably better done 
> the other way around -
> restrict as default and "alias" when necessary. Reusing the 
> keyword could work too,
> if template parameters is the only thing that can clash.
>
> artur

For this to work, the compiler would need to accurately imply 
aliasing with a 100% accuracy, to spit out errors. And if that 
was possible we would not need programmers hints at all. With 
restrict as a keyword, at least the programmer is aware of how 
"dangerous" that code is.
June 07, 2012
Re: C++Now! 2012 slides
On Thursday, 7 June 2012 at 16:05:00 UTC, bearophile wrote:
> "Now What?" by Sean Parent (Adobe).

I very much liked that presentation. It's nice to see someone 
looking at C++ in the big picture.

I also liked his comment on the "beauty" of std::pair

"Complete std::pair 372 Lines"

D suffers from this too. Here is std.algorithm.min (ignoring the 
definitions of CommonType, mostNegative, and isIntegral).


template MinType(T...)
{
    static assert(T.length >= 2);
    static if (T.length == 2)
    {
        static if (!is(typeof(T[0].min)))
            alias CommonType!(T[0 .. 2]) MinType;
        else static if (mostNegative!(T[1]) < mostNegative!(T[0]))
            alias T[1] MinType;
        else static if (mostNegative!(T[1]) > mostNegative!(T[0]))
            alias T[0] MinType;
        else static if (T[1].max < T[0].max)
            alias T[1] MinType;
        else
            alias T[0] MinType;
    }
    else
    {
        alias MinType!(MinType!(T[0 .. 2]), T[2 .. $]) MinType;
    }
}

MinType!(T1, T2, T) min(T1, T2, T...)(T1 a, T2 b, T xs)
{
    static if (T.length == 0)
    {
        static if (isIntegral!(T1) && isIntegral!(T2)
                   && (mostNegative!(T1) < 0) != 
(mostNegative!(T2) < 0))
            static if (mostNegative!(T1) < 0)
                immutable chooseB = b < a && a > 0;
            else
                immutable chooseB = b < a || b < 0;
        else
                immutable chooseB = b < a;
        return cast(typeof(return)) (chooseB ? b : a);
    }
    else
    {
        return min(min(a, b), xs);
    }
}


I find this very ugly. To be honest, I would be much happier 
without all that mostNegative and common type stuff. If I want to 
get the min between a short and an int I'll just cast them 
appropriately. I'd much rather have a simpler standard library 
than a complicated one for the sake of a little convenience.

Don't get me started on std.algorithm.find...


> The same question is valid for D. It seems important.

It is. D addresses vectorization a little with its array ops 
(although ISPC (http://ispc.github.com/) destroys both D and C++ 
in this arena) and we're yet to see if D provides scalable 
parallelism.
June 07, 2012
Re: C++Now! 2012 slides
On 06/07/12 20:19, Francois chabot wrote:
> On Thursday, 7 June 2012 at 17:17:07 UTC, Artur Skawina wrote:
>> On 06/07/12 18:04, bearophile wrote:
>>> Page 46: #pragma no_alias Are we going to need something like that (or "restrict") in D too?
>>
>> "restrict" functionality - yes, but it's probably better done the other way around -
>> restrict as default and "alias" when necessary. Reusing the keyword could work too,
>> if template parameters is the only thing that can clash.
> 
> For this to work, the compiler would need to accurately imply aliasing with a 100% accuracy, to spit out errors. And if that was possible we would not need programmers hints at all. With restrict as a keyword, at least the programmer is aware of how "dangerous" that code is.

Yes, it can't (always) be statically checked. But the alternative is restrict
proliferation; it applies not only to pointers, but also to slices. Hence defining
the language in a way that reduces the need for extra annotations would be best.
I'm not sure if that can be done safely for at least some subset of cases (function
arguments, mostly), that's why I said "probably" above. But it is something that
should be explored before blindly transplanting "restricted" to D.
While static compile-time checks aren't always possible, the rest could in theory
be handled by run-time checks in non-release mode. I'm not sure it would be enough.
A way to explicitly tag things as not aliasing anything else would also be handy;
'restricted' would work for that, maybe even 'uniq' could be overloaded and help.
This is eg for pointers extracted from some data structures, which are known to
not alias any others of the same kind present the current scope.

artur
June 07, 2012
Re: C++Now! 2012 slides
On 06/07/2012 08:34 PM, Peter Alexander wrote:
>
> I find this very ugly. To be honest, I would be much happier without all
> that mostNegative and common type stuff.
> If I want to get the min
> between a short and an int I'll just cast them appropriately.

The mostNegative and common type stuff is there to enable correct 
semantics for taking the minimum of signed and unsigned values. Minimum 
of short and int would work fine without that.

> I'd much rather have a simpler standard library than a complicated one for the
> sake of a little convenience.
>

'min' is not complicated.
June 07, 2012
Re: C++Now! 2012 slides
On 07.06.2012 22:34, Peter Alexander wrote:
> On Thursday, 7 June 2012 at 16:05:00 UTC, bearophile wrote:
>> "Now What?" by Sean Parent (Adobe).
>
> I very much liked that presentation. It's nice to see someone looking at
> C++ in the big picture.
>
> I also liked his comment on the "beauty" of std::pair
>

C++ has far worse size to power coefficient. The result is that generic 
programming is 2-10x longer ( + some pathological cases with up to 
~100). Not to mention readability.
I mean Boost doesn't do anything VERY advanced, it's just hard to keep 
focus on your goal while bending C++ compiler to your needs.

> "Complete std::pair 372 Lines"
>
> D suffers from this too. Here is std.algorithm.min (ignoring the
> definitions of CommonType, mostNegative, and isIntegral).
>
>
> template MinType(T...)
> {
> static assert(T.length >= 2);
> static if (T.length == 2)
> {
> static if (!is(typeof(T[0].min)))
> alias CommonType!(T[0 .. 2]) MinType;
> else static if (mostNegative!(T[1]) < mostNegative!(T[0]))
> alias T[1] MinType;
> else static if (mostNegative!(T[1]) > mostNegative!(T[0]))
> alias T[0] MinType;
> else static if (T[1].max < T[0].max)
> alias T[1] MinType;
> else
> alias T[0] MinType;
> }
> else
> {
> alias MinType!(MinType!(T[0 .. 2]), T[2 .. $]) MinType;
> }
> }
>
> MinType!(T1, T2, T) min(T1, T2, T...)(T1 a, T2 b, T xs)
> {
> static if (T.length == 0)
> {
> static if (isIntegral!(T1) && isIntegral!(T2)
> && (mostNegative!(T1) < 0) != (mostNegative!(T2) < 0))
> static if (mostNegative!(T1) < 0)
> immutable chooseB = b < a && a > 0;
> else
> immutable chooseB = b < a || b < 0;
> else
> immutable chooseB = b < a;
> return cast(typeof(return)) (chooseB ? b : a);
> }
> else
> {
> return min(min(a, b), xs);
> }
> }
>
>
> I find this very ugly.

Very straightforward, very convenient and (importantly) optimal result. 
Like in "I would have written it by hand exactly the same" barring 
generic grease like CommonType & mostNegative that resolves to nothing 
most of the time.

To be honest, I would be much happier without all
> that mostNegative and common type stuff. If I want to get the min
> between a short and an int I'll just cast them appropriately. I'd much
> rather have a simpler standard library than a complicated one for the
> sake of a little convenience.

STL & (to be frank )CRT is damn contrived. Ever tried reading printf 
source from GLIBC ? A polite recommendation: you'd better keep you 
favorite sedative nearby while you are at it.
Yet memset is fast as lightning and handles ton of cases with ease, and 
I don't have to think about it. The whole point of libraries FWIW.

> Don't get me started on std.algorithm.find...

Why not ? It's perfect example of goodness of generic programing, 
flexibility (for free) + speciality (when you need) for the win.
If you language lacks such construct you end up inveting ways around it:
- make findInt, findString, quickFindString, findPerson etc. * number of 
containters
- shoehorn everything into a simpler design: qsort, boxing-unboxing etc.


>
>
>> The same question is valid for D. It seems important.
>
> It is. D addresses vectorization a little with its array ops (although
> ISPC (http://ispc.github.com/) destroys both D and C++ in this arena)
> and we're yet to see if D provides scalable parallelism.

std.parallelism? It handles SMP without breaking a sweat.
GPGPU would be real nice though. And things like restrict(...) from C++ 
AMP could help, or better support for CTFE + DSLs.

-- 
Dmitry Olshansky
June 07, 2012
Re: C++Now! 2012 slides
On 07.06.2012 20:04, bearophile wrote:
> The slide packs of the conference C++Now! 2012 are available:
> https://github.com/boostcon/cppnow_presentations_2012
>

Thanks, nice stuff for my brain to chew on.

For one thing the ustring caught my eye. It goes in the right direction 
... for C++.

My first observations on the matter:

1) We all know COW strings are not good... because in C++ you have 
damned shared by default, folks!
That implies using atomic refcounting to be on the safe side, yet in D 
we have thread local by default, and ref-counting/COW is perfectly fine.
(for non-shared types).

2) Immutable strings have performance cost ... like tracking ownership 
and reference counting - unless you have GC by your side, in which case 
it's cheap and legal :)

3) Embeddable strings are not so hard to get in D, since there are 
char[...] arrays (that are even correctly value types!).

4) Small string optimization is kind of cool... for mutable strings 
mostly or as long as your GC sucks. (Small strings kind of prevent 
pooling, you know)

All that being said I could envision FlexString type in D, that does the 
following:
- easily integrates with string
- small string optimization (yay!)
- (maybe) allow any known encoding including legacy (and the list is 
extendable), convert on demand
- has plugable allocator (Andrei where was that nice design ? ;) )
- thus it could live on stack

Unlike c++ folks, we don't need:
- find and etc. to be members of string
- I personally against legacy encoding, let's stick with utf-8/utf-16
- customizable grow rates? (strange problem as I think preallocation is 
your beast friend where it may matter)

As far as small string goes I'd say a lot of containers would benefit of 
such packing, could be nice to generalize the concept.

The end of wish list:

Rope class would be cool, like... real cool. I guess std.container has 
to be package though :)


-- 
Dmitry Olshansky
June 07, 2012
Re: C++Now! 2012 slides
For some reason I found these docs really dull, to much 
rehashing of C++ 11 which is old hat now.

 The template stuff might be interesting if not for the knowledge 
that it will take absolutely forever to compile--
June 07, 2012
Re: C++Now! 2012 slides
On Thursday, 7 June 2012 at 20:04:56 UTC, Timon Gehr wrote:
> On 06/07/2012 08:34 PM, Peter Alexander wrote:
>>
>> I find this very ugly. To be honest, I would be much happier 
>> without all
>> that mostNegative and common type stuff.
>> If I want to get the min
>> between a short and an int I'll just cast them appropriately.
>
> The mostNegative and common type stuff is there to enable 
> correct semantics for taking the minimum of signed and unsigned 
> values. Minimum of short and int would work fine without that.

I know what it's there for, I don't think it is necessary. I 
don't think people should be taking the min of signed and 
unsigned values. I don't think it's worth cluttering the 
implementation for this minor convenience.


>> I'd much rather have a simpler standard library than a 
>> complicated one for the
>> sake of a little convenience.
>>
>
> 'min' is not complicated.

It's more complicated than it could/should be:

T min(T)(T x, T y) { return x < y ? x : y; }

To be honest, I don't think the variadic argument versions are 
necessary either as it is just duplicating the functionality of 
reduce.
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home