oneofthose

This seems to be Apple's answer to Google's RenderScript. It is too bad big companies (Google, Apple) are developing their own GPU software stack instead of building upon and furthering existing frameworks such as OpenCL. OpenCL desperately needs a kick in order to catch up with CUDA. Instead they are focusing on things like SyCL, hoping to catch up with already superior projects such as C++AMP. OpenCl should rather fix their poor specification and get implementers on the same page about it. The mobile community could have been a driving force. Instead, frustrated with what OpenCL is, mobile decided to roll their own. As always.

This is really nice. My note-taking+journal+reference management system recently converged on a vim+nerdtree+mardkwon+git+ssh+pandoc setup. I think NoTex does all that in one suite. I like it!

There are rumours that Nvidia will sooner rather than later support OpenCL 1.2 [0] - apparently CUDA 6 contains a stub library that has OpenCL 1.2 symbols and more.

[0] http://www.phoronix.com/scan.php?page=news_item&px=MTY2OTg

Some commenters seem to be offended by the way Bartosz presents his insights. Maybe some background is necessary. Bartosz has been pushing the C++ community for some time now to think more functional and consider the excellent properties of functional languages. His posts are great and his talks are very enlightening. I recommend his recent talk "I see a Monad in Your Future" [0] and I'm looking forward to his talk at C++Now.

Many of Bartosz' discussions focus on concurrency. It is one of the big and interesting problems we have at the moment. The criticism repeated here that "No one will ever be able to debug it" and the like is exactly what Bartosz sees in our future if we continue to program concurrent systems the way we do. He favours adoption of functional programming concepts to manage the complexity of concurrent systems. And I agree.

If code similar to the code in his blog is not acceptable in production code, a code review should make sure it never reaches production. An informed discussion about the pros and cons of such code could ensue during the code review, new insights are gained and everyone walks away a better, more knowledgeable programmer. I suspect this is one of Bartosz main goals.

[0] https://www.youtube.com/watch?v=BFnhhPehpKw

You're right, I completely misunderstood the purpose of Halide. I read up on it and I see now that they simplify how developers can do the copious implementation by hand. The schedule must be specified by the developer, the compiler doesn't to that.

Since this is a language and a compiler, my guess would be the answer to your question is: the compiler will optimize for the underlying platform. The whole point of Halide is stated in their abstract: "... make it easier to write high-performance image processing code" which is the exact opposite of "hand optimization". Halide allows developers to express what to do in a powerful, domain specific language - the compiler takes care of the "how".

This approach makes a lot of sense: abstract the annoying low level architecture details. They have a lot of targets which is fantastic: x86/SSE, ARM v7/NEON, CUDA, Native Client, and OpenCL. Let the architecture specialist worry about the architecture specifics. The disadvantage: the achieved performance then depends on quality and wisdom of the compiler. But once certain things are optimized for a specific architecture, every user will benefit.

How they do it on the compiler end of things, I'm not sure. There are a number of techniques. Among the simpler is auto-tuning. There is also a new term: "copious-parallelism" [0]. It acknowledges that to achieve performance portability across platforms, algorithms must offer explicit ways of parametrization and tuning to adapt to different platforms. I think this is the right concept but believe that it could be implemented within the compiler. The domain specialist should not have to think about those things.

[0] http://www.hpcwire.com/2014/01/09/future-accelerator-program...

I wonder if this good be a Getting things Done tool. You'd probably need multiple of those trees and a way to put simple, wiki-like multiline articles (maybe markdown syntax?). I'd use something like that!

This seems to be a great idea. I really like everything about it, I would love to use it (even though I don't own smartphone). Too bad Apple did reject it. One sentence that made me quite happy in this article is:

"Hueman is free and anonymous, and to create that seamless experience, it needs to store data on your phone. If it was a web page on mobile safari, that data is more ephemeral."

If the Hueman developers read this: have you considered something like unhosted [0] for your application? It should be easy enough to implement.

[0] https://unhosted.org/

Excellent article and almost 6 years old. There are many projects to mention here but so far none of them took of as far as I know. Or did they?

After publishing my own rant about the same topic [0], Dave Winer commented via Twitter and argued that RSS is a very successful tool that decentralizes the web. I didn't understand his point at the time but today I think he is absolutely right.

His point was that when trying to fix the problem we should look at what already exists and works. Why did RSS succeed? Probably because it solved a problem for many people. It did not try to reinvent old things in a decentralized way but offered real benefits. Another good example for this git vs svn (centralized vs decentralized revision system).

[0] http://www.soa-world.de/echelon/2011/09/the-decentralized-we...

Here's a the dramatized version of David Grieg's 2012 play "The Letter of Last Resort" produced for BBC Radio 4. I can recommend it.

https://www.youtube.com/watch?v=PwY9th-vmNY

A book that some believe influences Russia's strategy is "Osnovy geopolitiki: Geopoliticheskoe budushchee Rossii" (Foundations of Geopolitics: The Geo-political Future of Russia) by Alexander Dugin. It describes the path to an Eurasian Empire that says about Ukraine "with the exception of its three westernmost regions—Volhynia, Galicia, and Transcarpathia—Ukraine, like Belarus, constitutes an integral part of Russia-Eurasia". [1]

[0] http://en.wikipedia.org/wiki/Foundations_of_Geopolitics [1] http://www.hoover.org/publications/hoover-digest/article/807...

I'm working on a low level library that - in theory - will allow you to write code once and compile it for OpenCL or CUDA backends [0]. It is still pre-alpha and completely unusable but maybe you want to have a look or keep an eye on it.

I am trying to see if I can put a) a portable interface together (for both writing kernels and the coordination of cards, contexts, memory, queues/streams etc.) and b) if the performance is portable. I can already see that performance for trivial kernels is portable from AMD to NVIDIA but as soon as I go to the Intel PHI things are suddenly very different.

[0] https://github.com/sschaetz/aura

I'm not overly familiar with OpenCL on the CPU myself, I only know it works. But people are doing this [0,1]. Whether or no it uses SSE/multiple cores depends on the specific OpenCL backend that is used. But it should use both multiple cores and SSE. I know Intel does this for both their Phi and regular CPUs.

For me, the most important thing in both CUDA and OpenCL is the programming model. It allows us to describe data parallel problems and related data (in)dependence explicitly. Compilers should be (and already are) able to generate efficient code from this. It is not as nice as it could be, we have to write kernels by hand etc. But there are libraries that make our lives easier (we discussed them earlier). And there is also C++ AMP which tries to integrate better. Yet still, while we have all these options and we can solve most of our problems with more or less effort and elegance, I believe there must be something better out there: the right way to describe data parallel and task parallel problems as well as concurrency etc. Maybe the FP guys are on to something, I don't know. I'll be on the lookout.

[0] http://www.pds.ewi.tudelft.nl/fileadmin/pds/homepages/shenji... [1] http://comparch.gatech.edu/hparch/papers/lee_plc2013.pdf

I didn't know about Theano, thanks for the hint. I have been focused on C++ libraries only, apparently missing a huge body of work.

CPU is supported through OpenCL by these libraries. Remember, OpenCL code can run on CPUs. As for Aura, it is pre-alpha, not a lot of functionality there yet, I'm still figuring out the interface. So not usable yet, but keep an eye on it, it will be.

There is also VexCL [0] and Boost.Compute [1]. Both are quite capable. I myself am working on something similar - it is called Aura but still a long way to go [2]. ViennaCL, VexCL and Boost.Compute focus on maximizing programmer productivity. Converting existing code from i.e. Matlab to accelerator hardware is trivial using these libraries and you get excellent performance quickly. Furthermore, NT2 doesn't get nearly as much publicity as it deserves [3]. Not only does it provide an incredible number of functions ready to use, but it also exploits the vector processing capabilities of modern CPUs. These capabilities are too often ignored by developers or left for non-optimal compiler optimizations to exploit.

In my own library Aura, I focus on maximizing performance (over developer convenience). The target audience are developers of real-time applications that need every last drop of performance from their hardware, while still maintaining a sane and cross-platform API. I strive for a Boost.Asio for accelerator developers. Aura has a already a rudimentary wrapper for clFFT, clBLAS is in the works. So the idea is to, for each platform, utilize optimal vendor-supplied library functions and combine them in a coherent interface.

[0] https://github.com/kylelutz/compute

[1] https://github.com/ddemidov/vexcl

[2] https://github.com/sschaetz/aura

[3] https://github.com/MetaScale/nt2

One aspect to the "instantly hook a user" theory that I have not seen mentioned here is the following:

Taking a potent drug like heroine or cocaine for the first time is described by some users as "pushing open a door to a very enjoyable place you did not know existed". Once this door is open, you will always know that this place exists, you can not "unknow" the experience.

While some people might be able to handle the knowledge of this enjoyable place and are able to choose when and if to go back, some might not be able to. Therefore I believe it makes sense to tell people not to open the door at all.

I also can imagine that the first time with these potent drugs is a positive experience for many, unlike the first cigarette or the first beer a person ever tries. The second cigarette is not smoked because the first was so good.

There's Crypto-Stick [0], a security USB key with many interesting features. It's essentially an OpenPGP card with some added features.

What excites me about their project is a very simple file-system based interface they are planning to implement for their upcoming version. Plug the key in, it looks like a regular USB key, put a file in a specific place, get an encrypted/signed/whatever file from the file system from another place. No driver or software required. I hope their project takes off and people start buying these keys. The price is a little high right now (59,00 €) and it is currently not available.

[0] https://www.crypto-stick.com/

I don't see how

compute a() in parallel with b() and

handle mouse events concurrently (could be a()) with keyboard events (could be b())

differ and how does

compute a(0), a(1), ..., a(N) in parallel differ from

handle events from 1000 sockets concurrently which would be something like a(event0) a(event1)?

Don't we require the same tools for "task parallel" and "task concurrent" as well as "data parallel" and "data concurrent"? To me they don't seem orthogonal but I believe they are very much the same thing.

They did demonstrate quantum behavior in a Nature paper [0] they published in 2011.

[0] http://www.nature.com/nature/journal/v473/n7346/full/nature1...

I might be confusing things here but does concurrency, at least the definition give here, not directly map to task parallelism?

Task parallelism and data parallelism are two important concepts and the tools we need to implement them are very different. The two words used by the author to convey the difference between those two concepts are not chosen optimal in my opinion. There seems to be a hierarchy between concurrency and parallelism whereas task parallelism and data parallelism are directly comparable.

Why not include functionality to connect different installations to one large, distributed database?

A similar talk was given at GTC (GPU Technology Conference), it is S3418: Porting Source to Linux: Valve's Lessons Learned. The video is available for attendees right now. Videos should be available to the general public 30 days after the conference ended. This is the website: http://www.gputechconf.com/page/home.html

Although I like vim for programming and config file editing, I is not the perfect solution for me for note-taking. I like more markup and a GUI with some functionality. The perfect solution for me is Tomboy[0]. It is included in many Linux distributions and there is an installer for Mac OS and Windows. I love the SSH synchronization mechanism that keeps my notes secure on a virtual hosted server and up to date across my computers.

[0] http://projects.gnome.org/tomboy/

I do exactly the same thing. It works really great for me. An additional plus if you go this route is the tagging feature of tiling window managers. This allows you to have multiple views. I use for example one e-mail/web view, one development view (vim in multiple consoles), one server view (consoles connected to various remote systems) one Matlab view and of course one music player view.

One often forgotten but truly fascinating character in the early days of computing is Konrad Zuse [0] who arguably built the first computer. If you are interested in computer history make sure to read his autobiography "The Computer - My Life". At some point he was financed by Nazi-Germany arms producers. About this he said (rough translation by me from German):

Too often is the inventor the Faustian idealist who tries to change the world but fails due to the harsh reality. If he wants to implement his idea, he has to get involved with powers, whose sense for reality is sharper and more pronounced than his. Today such powers are, without expressing a value judgment, military and management. [...] In my experience, chances are slim to defend oneself against such pacts.

[0] http://en.wikipedia.org/wiki/Konrad_Zuse

From my experience, a fair amount of scientific computing is done on Windows through Matlab.

I would be willing to set up a bridge but how can we get the bridge IPs to those who need them?

> long after the world has moved on to Java, C#, Python, Ruby, JavaScript, etc.

I don't think this is true for everyone. In fact I believe recently we have seen a renaissance of native code. C++ is the number one language for that. Those higher level languages waste a lot of cycles. You pay the warm and fuzzy feeling during development with performance and/or energy.

You can of course implement the same functionality using either C or C++. I agree - the two implementations would be very similar. But I don't think this is the point Bjarne is trying to make.

C++ challenges you to think in terms of types instead of functions. This is in my opinion often a more natural way to approach and solve problems and thus produces more elegant code. Because of that, C++ is a very powerful tool for library developers - you can design libraries that allow domain-specific developers to write expressive code that performs as if you had written more verbose C code. And this C++ code is not only more expressive for your fellow co-workers to read and understand but also in some cases for the compiler. This is the reason why C++ code can sometimes be compiled to faster machine code: you can give the compiler more information about what you actually try to accomplish (keyword: template meta-programming).

As with most things there is no definite answer. C code can be quite elegant and appropriate as well.

It is undocumented but you can get a fairly decent idea of what is going on if you have a good understanding of such architectures in general and from the sparse documentation they provide, if you run microbenchmarks and use tools such as decuda (https://github.com/laanwj/decuda/wiki).

Also people working with those devices are often scientists that are eager to share what they found out (if only to say "You're doing it wrong!"). See for example Vasily Volkov's work here http://www.cs.berkeley.edu/~volkov/