matt_d

I realize that this is another topic, although in a somewhat similar context, so I thought I may just ask: Have there been any advances in reducing the page walk latency?

I'm thinking of the virtual address translation costs having impact on the run times of common algorithms, e.g., as demonstrated in the following work by Jurkiewicz & Mehlhorn: http://arxiv.org/abs/1212.0703

The recent research I'm aware of is, e.g., Generalized Large-page Utilization Enhancements (GLUE) mechanism, proposed in "Large Pages and Lightweight Memory Management in Virtualized Environments" (from this year's Micro): slides: https://dl.dropboxusercontent.com/u/36554102/BPC-1.pdf ; paper: http://paul.rutgers.edu/~binhpham/phamMICRO15.pdf

Admittedly, it focuses specifically on one aspect (the Double Address Translation on Virtual Machines issue in the Jurkiewicz & Mehlhorn context).

What I'm wondering about is: Has there been any progress on that on the "practical implementation" side, in the recent/coming Intel (or other, for that matter) CPUs?

For more (in the x86-64 specific context), see also http://tinyurl.com/x86-64-assembly

> I have no problem using GPUs- those are relatively easy to program now and we've raised a generation of grad students who can write codes to those platforms. They've proved their way.

> It's ASIC and FPGAs which aren't competitive in this area.

Out of curiosity, I'm wondering, what about the solutions directly attacking this problem -- i.e., ease-of-programmability & time-to-market?

For instance, I'm thinking of the Altera Software Development Kit (SDK) for OpenCL (AOCL) here -- I don't suppose this would be necessarily worse than "easy to program GPGUs", especially when targeting embarrassingly parallel problems (so, any overheads due to OpenCL model <-> FPGAs impedance mismatch, present due to OpenCL admittedly being originally designed for a very different hardware, could be in fact minimized here)?

In particular, the OpenCL examples don't look particularly complex (speaking as someone with GPGPU background): https://www.altera.com/support/support-resources/design-exam...

In addition, the capabilities present that allow to optimize-around loop-carried dependencies (a _huge_ problem for GPGPUs) like the pipeline parallelism made use of in the HPC examples (like the stateful PRNG; and which makes sense due to the specific nature of FPGA hardware -- more on that in a moment), seem to make this a more attractive platform for a significant set of number-crunching workloads.

This may very well be the right-tool-for-the-right-job decision. There are some very different trade-offs present regarding the kinds of parallelism natural to GPUs vs. FPGAs (admittedly it would be more precise to say "SPMD" instead of "SIMD" in the following, but I don't think it takes away from the key point): "The key difference between kernel execution on GPUs versus FPGAs is how parallelism is handled. GPUs are “single-instruction, multiple-data” (SIMD) devices – groups of processing elements perform the same operation on their own individual work-items. On the other hand, FPGAs exploit pipeline parallelism – different stages of the instructions are applied to different work-items concurrently."

Source: https://www.altera.com/en_US/pdfs/literature/wp/wp-201406-ac...

I don't believe that either kind is universally/strictly "better" than another, so it's all about the use cases -- at least that's how I think about it, perhaps I'm missing some other trade-offs?

Regarding the I/O-bound problems: Isn't this another reason for the attractiveness of high-performance FPGAs -- like, say, Stratix, compared to GPUs? What I'm thinking of is that you can have plenty (relative to GPUs) of very high performance (here, relative to both GPUs -- as well as high-end CPUs) SRAM caches, e.g., QDRII+ SRAM: http://www.cypress.com/products/sync-sram

For instance, one example would be the QDRII+ SRAM options in the block diagram here: http://www.alteraboards.com/product/s5-pcie-hq/

Myself, I'm still unconvinced about the best choice w.r.t. the consistent performance/price ratio maximization (both the device as well as the programmers costs) -- both high-end FPGAs as well as high-end GPUs seem rather on the expensive side, either way (well, and very high-end CPUs too, for that matter).

Completely independently of the above: I'm wondering, what do you think are the reasons for Intel investing in the partnership with Altera and developing its Xeon+FPGA hybrid hardware? I presume there must be something to it, it's a potentially large amount of resources to dedicate for a hardware project.

There's been an interesting talk on this a few months ago:

- http://blog.cr.yp.to/20150314-optimizing.html

- (PDF) http://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf

Discussions:

- https://news.ycombinator.com/item?id=9202858

- https://news.ycombinator.com/item?id=9396950

Abstract: Object-oriented programming is often characterized as encapsulation plus polymorphism plus inheritance. The original Simula67 demonstrated that we could do without encapsulation and Kristen Nygaard insisted that some OOP could be done without inheritance. I present generic programming as providing encapsulation plus polymorphism. In C++, this view is directly supported by language facilities, such as classes, templates and (only recently) concepts. I show a range of type-and-resource-safe techniques covering a wide range of applications including containers, algebraic concepts, and numerical and non-numerical algorithms.

Source: http://drops.dagstuhl.de/opus/volltexte/2015/5212/

Computer History Museum: http://www.computerhistory.org/

In particular, Software Preservation Group (SPG): http://www.computerhistory.org/groups/spg/ http://www.softwarepreservation.org/

Even more in particular ;-) -- the videos at the Oral History Collection: http://www.computerhistory.org/collections/oralhistories/

They're also on YouTube -- https://www.youtube.com/user/ComputerHistory/playlists -- but the ones above have synced transcripts.

To get a flavor, take a look at the one with Bjarne Stroustrup, really enjoyed it: http://www.computerhistory.org/collections/oralhistories/vid...

// More in this category (with some big names): https://www.youtube.com/playlist?list=PLQsxaNhYv8daKdGi7s85u...

Futures can be created with promises:

- http://en.cppreference.com/w/cpp/thread/future

- http://en.cppreference.com/w/cpp/thread/promise

- https://en.wikipedia.org/wiki/Futures_and_promises

- http://docs.scala-lang.org/overviews/core/futures.html

> In general, any kind of analysis like the borrow checker will reject some valid programs, as it pays to be extra conservative. You then slowly expand the set of accepted programs, until hopefully, it matches the true set of valid programs, without accepting invalid ones.

I'm wondering, is this possible in principle?

Context: I'm thinking in terms of sound-and-decidable type-checking conservativeness [0], but perhaps that's a bad way of thinking about this? Perhaps borrow-checking is a special-enough case of type-checking that somehow isn't afflicted by this (how?) or gives up the soundness (does it?)?

[0] "A sound type system with decidable type-checking (and possibly decidable type inference) must be conservative." -- http://gallium.inria.fr/~remy/mpri/cours1.pdf

See also: https://books.google.com/books?id=7Uh8XGfJbEIC&pg=PA134

So, like http://gkoberger.github.io/stacksort/? ;]

Thanks, sounds interesting! BTW, out of curiosity, is there a way to track developments in RStudio like the one you've mentioned?

// Preview Release Notes make a note of "Code completion for C/C++", but don't mention libclang (use of which is interesting on its own, IMHO, since it better indicates the quality improvement to expect): http://www.rstudio.com/products/rstudio/download/preview-rel...

Yes!

Incidentally, I already have a feature request! :-)

As a heavy C++ user (also using R for EDA & analytics), one feature I love about PTVS is mixed-mode debugging: https://pytools.codeplex.com/wikipage?title=Mixed-mode%20deb...

Any chance of that for "RTVS"? Preferably with cooperation with Rcpp, http://rcpp.org/

(There's some basic support for Rcpp in RStudio -- https://support.rstudio.com/hc/en-us/articles/200486088-Usin... -- but it's rather limited.)

Hi! Looks interesting!

I have a question -- in particular, the blog post mentions that the framework "includes both server and client code", any my question is about the second part :-)

I'm wondering, how does it compare to the other C++ HTTP client solutions: Is it closer to higher-level libraries like cpp-netlib, Casablanca, or POCO -- or more on a lower-level / comparable to Asio (or Boost.Asio)?

In your view, what are the main relative advantages/disadvantages (namely in the scenario mentioned in the blog post, i.e., integration into existing applications)?

A side note: I think you may be able to simplify `is_compatible` by getting rid of hand-rolled `yes` and `no` constants (and subsequent manual size-testing for `value` computation) and using `std::true_type` and `std::false_type`, respectively: http://en.cppreference.com/w/cpp/types/integral_constant

Edit: noticed you're using these in another place (`compatible` implementation), so perhaps there's a reason for a different approach?

Thanks for the explanations!

Thanks for the reply!

Interesting that the constness in `for each` caused confusion (did it offer a `mutable` opt-in, though?), would intuitively expect it to be the POLS behavior. I guess given that you were probably receiving feedback on that, I will take it as something to be acknowledged.

I can see the reference semantics point, in this context the difference from the lambdas seems to make more sense.

// Just to explore another avenue, again mostly out of curiosity :-), how realistic (from the impl. POV) would be to have value-semantic range-based `for` with _mandated_ copy elision whenever possible?

True about `std::for_each`, that's what I've referred to as the "allowance" for the mutable iterators, wasn't aware about the grouping being merely a historical artifact, though. I've always felt a bit dirty using it for mutation[1], it seems that maybe unnecessarily so :-)

// [1] -- perhaps due to the algorithm being specified in terms of the InputIterator concept; hm, that being said, I suppose that while it only guarantees that we can read (dereferenced) `it`, it doesn't say that `it` _itself_ has to be immutable (right?), so it could be that I should think of a better metaphor to internalize. How do you think about InputIterators?

Out of curiosity, how about making `const` the default and requiring `mutable` for mutation?

There's already a Standard precedent in form of C++11 lambdas -- and const-by-default has some technical niceties (perhaps simplicity, too -- arguably making this the default removes some complexity from the language from the beginner's point of view, e.g., by preventing accidental mutation) that may make this worth it.

// I see that you addressed the constness in A17, but I believe allowing the `mutable` opt-in, as in the lambdas, takes care of the "limiting" aspect; "confusing", OTOH, is a matter of taste -- after all, `std::for_each` operates on InputIterators as well (thus, perhaps the similarity with a non-modifying nature[1] of a Standard Library analog is arguably preferable from the consistency / least-surprise-principle point of view?), and, again, lambdas also have constness by default.

Thoughts?

// [1] -- in principle, at least (for completeness, there's an allowance for nonconstant functions w/ mutable iterators)

Try "Practical x64 Assembly and C++":

- http://www.whatsacreel.net76.net/asmtutes.html

- https://www.youtube.com/playlist?list=PL0C5C980A28FEE68D

Covers x86-64, MMX, SSE2/3/4, AVX.

The author, Chris Rose, has also written a free e-book: "Assembly Language Succinctly" -- (PDF) https://www.syncfusion.com/Content/downloads/ebook/Assembly_...

HTH!

0. Books--one of these: http://isocpp.org/get-started

Personally, if you aren't new to programming per se, I'd go with "C++ Primer" by Lippman/Lajoie/Moo since it smoothly integrates modern C++11 throughout the entire text (instead of sticking it into a separate section, as some of the other books do).

After that, "C++ Concurrency in Action: Practical Multithreading" by Anthony Williams: http://www.manning.com/williams/

...and then the rest of the books from the isocpp list (e.g., Josuttis).

1. Libraries:

The rich ecosystem of available libraries is one of my primary reasons for using C++ for numerics :-)

In fact, it's rich enough that it may be best if you were to specify what kind of number crunching you're interested in -- right now I can only try to give you a very broad/big-picture list of some that I've found useful.

The Standard Library supports (P)RNG with a variety of statistical distributions: http://en.cppreference.com/w/cpp/numeric/random

- Boost.Math Toolkit: http://boost.org/libs/math // and more broadly: http://boost.org/doc/libs/?view=category_Math // and even more broadly ;-): http://www.boost.org/doc/libs/?view=categorized - Eigen: http://eigen.tuxfamily.org/ - GPGPU: http://www.soa-world.de/echelon/2014/04/c-accelerator-librar... - MLPACK: http://mlpack.org/ - NLopt: http://ab-initio.mit.edu/wiki/index.php/NLopt_C-plus-plus_Re... - OpenCV: http://opencv.org/ - Odeint: http://www.odeint.com/ - POCO: http://pocoproject.org/ // note: not numerics, but when you need to exchange data over the net/web, these are pretty good for that :-) - QuantLib: http://quantlib.org/ // note: QuantLib is primarily for quantitative finance, but also has math components: http://quantlib.org/reference/group__math.html - SOCI: http://soci.sourceforge.net/ // note: not numerics, but for when you need database access, it has pretty clean API and is easy to use :-)

2. Talks:

* C9 Going Native: http://channel9.msdn.com/Shows/C9-GoingNative

In particular: + "Bjarne Stroustrup - The Essence of C++: With Examples in C++84, C++98, C++11, and C++14" - http://channel9.msdn.com/Events/GoingNative/2013

+ "Sean Parent - C++ Seasoning" - http://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoni...

* BoostCon / C++Now!: https://github.com/boostcon/

There's _lots_ of interesting talks, so explore yourself :-)

For instance, 2013 Keynote: "Dan Quinlan: C++ Use in High Performance Computing Within DOE: Past and Future" // http://2013.cppnow.org/session/keynote/

// IMHO, it's worth watching these for staying up to date with the broader developments in the field -- e.g., according to the speaker (given who he is I'd assume credibility) most national labs, including Lawrence Livermore National Laboratory in particular, are quite actively adopting C++ (not C) and have been turning away from Fortran for some time now.

HTH! :-)