Skip to content

Conversation

salmanulhaq
Copy link

Added clear_persistent_cache() in program_cache.hpp which removes .boost_compute directory.

Minor update to persistent caching: instead of computing sha1 hash of just program source, I've also added compiler options and selected device's name so if anything changes, program would be built again.

// Path delimiter symbol for the current OS.
static const std::string delim = boost::filesystem::path("/").make_preferred().string();

// Path to appdata folder.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of copying these lines, could you just call detail::appdata_path() directly?

@kylelutz
Copy link
Collaborator

Also, could you open a pull request against the develop branch (that's where we do testing/integration before updating the more stable master branch). Thanks!

@@ -82,6 +82,25 @@ class program_cache : boost::noncopyable
m_cache.clear();
}

/// Clears persistent cache by deleting the boost_compute folder
void clear_persistent_cache()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this could be a static method (so users can just call program_cache::clear_persistent_cache() directly without having to get/create a program_cache object).

@ddemidov
Copy link
Contributor

Regarding @keryell's note: one possible solution is to make compute::detail::sha1 a functor, where operator()(const std::string&) calls process_bytes() repeatedly (see the current implementation of details::sha1 here). It could also provide a conversion to string operator, so that computing the hash could be:

detail::sha1 hash;
hash(source);
hash(device_name);
hash(compiler_version);

load_program_binary(hash, context);

@keryell
Copy link
Contributor

keryell commented Mar 22, 2015

Yes you are right, since boost/uuid/sha1.hpp has already the right interface. So there is no need to have a Merkle's tree approach that would create several sha1 intermediate objects.
Great!

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants