Looking at the performance page of Boost.Coroutine, symmetric coroutines seem to be significantly cheaper to construct than asymmetric ones, by about 50x. This seems surprising as symmetric coroutines seem to provide a more general abstraction. Is there some functionality in asymetric coroutines that justifies this cost?
I should also add that, in the context of asymetric coroutines, the construction cost is about 500x the cost of a context switch, so it could easily be the bottleneck in an application.
Related
It has always been hard to me to understand why OWL-DL reasoning is so efficient in real-world application.
For example, I often use ontologies which are in ALCQI fragment processed by the Fact++ reasoner, and it is well-known that concept satisfiability is PSPACE-complete and logical implication is EXPTIME.
Here, at slide 29 is clearly stated that:
the state-of-the-art DL reasoning systems are based on tableaux techniques and
not on automata techniques
+easier to implement
-not computationally optimal (NEXPTIME, 2NEXPTIME)
-->the systems are highly optimized
despite the high computational complexity, the performance is surprisingly good in
real world applications:
knowledge bases with thousands of concepts and hundreds of axioms
outperform specialized modal logics reasoners
From one side it is proven that computationally they are not optimal, on the other hand they are efficient in the real world application even for large input, but I can't find sources online that explain why this is possible and how this is handled.
Definitively, I'm missing this step that I'm really trying to understand.
Does anybody here have an idea?
I'm wondering why is the Trust Region Policy Optimization a On-policy algorithm?
In my opinion, in TRPO, we samples by the old policy and update the new policy and apply the importance sampling to correct the bias. Thus, it is more like a off-policy algorithm.
But recently, I read a paper which said:
In contrast to off-policy algorithms, on-policy methods require
updating function approximatorsaccording to the currently followed
policy. In particular, we will consider Trust Region
PolicyOptimization, an extension of traditional policy gradient
methods using the natural gradient direction.
Does any point I misunderstand?
The key feature of on-policy methods is that they must use the estimated policy in order to interact with the environment. In the case of Trust Region Policy Optimization, effectively it adquires samples (i.e., interact with the environment) using the current policy, then updates the policy and uses the new policy estimation in the next iteration.
So, the algorithm is using the estimated policy during the learning process, which is the definition of on-policy methods.
I'm exploring currently the safe aspects of Java. Of course one of the first things I looked up, was the whole decoding point.
Mentioned decryption technologies
After some time of studying I learned some thing about following cryptography technologies:
MD5
SHA
PBKDF2WithHmacSHA1
Why am I asking this question ?
I know that roughly speaking SHA1 is safer than MD5, with PBKDF2WithHmacSHA1 being the safest. But now I have to ask myself, why in some applications an encryption like MD5 or SHA1 is still used, whereas in this case PBKDF2WithHmacSHA1 is more secure? I am of course aware that the chance to take advantage of the best technology comes only in rare cases (reduction of brute force speed / risk of collision).
But in spite of everything the implementation time is a little bit longer and in return you get a more secure encryption.
My final question
In short, my question is why not all applications always use the best encryption technology, even if they don't necessarily need it? I mean the only drawback is that it takes a little bit longer to implement.
In addition
I don't think that the loss of speed is a reason, to not use the best encryption technologies.
The goal is to make the hash function slow enough to impede attacks, but still fast enough to not cause a noticeable delay for the user. From here
A couple of resons comes to my mind:
Lack of knowledge - one do not know enough about cryptography to write good code (should I choose PBKDF2WithHmacSHA1, PBKDF2WithHmacSHA512, bcrypt, Argon2?)
Legacy systems - hashed values can't be unhashed, thus hashed passwords can't be converted to new cryptography scheme
No library /available/supported/NIST compliant/ etc. by the operating system
I have read a number of articles and got confused.
Opinion 1:
2PC is very efficient, a minimal number of messages are exchanged and latency is low.
Source:
http://highscalability.com/paper-consensus-protocols-two-phase-commit
Opinion 2:
It is very hard to scale distributed transactions to high level, moreover they reduce throughput. As 2PC guarantess ACID It puts a great burden due to its complex coordination algorithm.
Source: http://ivoroshilin.com/2014/03/18/distributed-transactions-and-scalability-issues-in-large-scale-distributed-systems/
Opinion 3:
“some authors have claimed that two-phase commit is too expensive to support, because
of the performance or availability problems that it brings. We believe it is better to have
application programmers deal with performance problems due to overuse of transactions
as bottlenecks arise, rather than always coding around the lack of transactions. Running
two-phase commit over Paxos mitigates the availability problems.”
Source: http://courses.cs.washington.edu/courses/csep552/13sp/lectures/6/spanner.pdf
Opinion 4:
The 2PC coordinator also represents a Single Point of Failure, which is unacceptable for critical systems - I believe it is a coordinator.
Source: http://www.addsimplicity.com/adding_simplicity_an_engi/2006/12/2pc_or_not_2pc_.html
First 3 opinions contradict each other. The 4-th one I think is correct. Please clarify what is wrong and what is correct. It would be great also to give facts why that is.
The 4th statement is correct, but maybe not in the way you are reading it. In 2PC, if the coordinator fails, the system cannot make progress. It therefore often desirable to use a fault-tolerant protocol like Paxos (see Gray and Lamport for example), which will allow the system to safely progress when there are failures.
Opinion 3 should be read in context of the rest of the Spanner paper. The authors are saying that they have developed a system which allows efficient transactions in a distributed database, and that they think it's the right default tradeoff for users of the system. The way Spanner does that is well detailed in the paper, and it is worth reading. Take note that Spanner is simply a way (a clever way, granted) of organizing the coordination which is inherently required to implement serializable transactions. See Gilbert and Lynch for one way to look at the limits on coordination).
Opinion 2 is a common belief, and there are indeed tradeoffs between availability and richness of transaction semantics in real-world distributed systems. Current research, however, is making it clear that these tradeoffs are not as dire as they have been portrayed in the past. See this talk by Peter Bailis for one of the research directions. If you want true serializability or linearizability in the strictest sense, you need to obey certain lower bounds of coordination in order to achieve them.
Opinion 1 is technically true, but not very helpful in the way you quoted it. 2PC is optimal in some sense, but seldom implemented naively because of the availability tradeoffs. Many adhoc attempts to adress these tradeoffs lead to incorrect protocols. Others, like Paxos and Raft, successfully address them at the cost of some complexity.
This might be considered an odd question - but i'm looking for a "cheat sheet" that describes (for example) how "expensive" various database operations are.
I'm looking for a theoretical understanding (perhaps backed by statistical data).... for example I can guess that a select operation with an order by statement is slower than a plain select one.
But i've heard that JOINs are the moste "expensive" ones but i'm not sure of that... so it would be good to get some proof of that...
Not sure I've ever seen such an item. It's quite a complex field, and a locally cheap operation might not be globally optimal if it precludes a cheaper strategy from being used across the whole query.
For example, table scans are supposed to be expensive, but are often the cheapest operation on a large table if more than a few percent of records need to be selected. This is because a table scan is largely composed of sequential I/O, which can cover a large volume of streamed data relatively efficiently in comparison to a large number of random I/Os that (for example) a bookmarking operation might use.
A query optimisation tutorial is really too big to fit into a stackoverflow posting (at least in the time I have available) but there are many resources on the web, and quite a few print books that give it a good treatment. It is also somewhat platform dependent, although the principles often apply across platforms.
SQL Server is a good system to experiment with as the front-end tool shipped with it has a query plan visualisation feature, even on the free 'express' versions.