902 karma · joined May 12, 2011
Java does for integer http://docs.oracle.com/javase/8/docs/api/java/util/concurren...
You can find similar classes in the java.util.concurrent.atomic package. http://docs.oracle.com/javase/8/docs/api/java/util/concurren...
I'm not sure what requirements you have for a concurrent struct, but Java has classes to atomically manipulate int and long fields of a class.
I'm not arguing your general point (in fact, I agree with it), I'm just supplying some extra information of a language that you apparently don't know.
Type your answer in the box, if you type 2 or more characters, there will be an auto complete list of matches.
If nothing happens when you choose an answer, then it's wrong.
When you choose the right answer, it will immediately switch to the next question.
If you don't know the answer you can click Forfeit or press Esc. To get rid of the correct answer that pops up when you do so and go to the next question, you have to press Esc (I didn't find a way to go to the next answer just by clicking with the mouse).
Send three "heap-minimize" notifications in a row. Each notification triggers a global garbage collection followed by a cycle collection, and causes the process to reduce memory usage in other ways, e.g. by flushing various caches.
I believe the new baseline compiler is included in this release as described here:
https://blog.mozilla.org/javascript/2013/04/05/the-baseline-...
If that is the case it's the most interesting new feature for me, but I'm a compiler guy :-)
I haven't used any edition of the Python cookbook, but I've used the Perl cookbook and it's just like you described. I have also heard and read that the O'Reilly cookbooks are known (famous even?) for being the kind of books that you described.
When I just visit that page it suggests that I download version 10.3.183.10, but if I choose to download for another OS or browser version 11 is available for Windows, Mac OS X and Linux. 64 bit version for Linux is finally stable.
You can also have a look here: http://www.adobe.com/software/flash/about/ where version 11 is listed as the current version.
Version 11 isn't available from the Adobe Yum repository yet, I will probably wait for that before I try it.
I've seen several open source projects link to that document as well, so it might be what you are looking for.
Dijkstra deals with what index start with as well, but it comes out as a consequence of which bounds to choose for a range, so it's rather short.
From the article:
When dealing with a sequence of length N, the elements of which we wish to distinguish by subscript, the next vexing question is what subscript value to assign to its starting element. Adhering to convention a) yields, when starting with subscript 1, the subscript range 1 ≤ i < N+1; starting with 0, however, gives the nicer range 0 ≤ i < N.
Is it really necessary for the GC to be re-entrant to run the interpreter in parallel? Couldn't you have the interpreter running in parallel and then when there is a need to run the GC you have a global GC lock that prevents all threads from running - a stop the world GC. The application runs for a longer time than the GC, right? So it would be a win and a step in the right direction? I believe the early Java mark and sweep GC was like that, and then later Sun developed several different kinds of concurrent and parallel GCs.
> Official PyPy Status Blog
Oh I read that every time they write something. :) But I started reading it in late 2010 and I haven't gone back to the archives, I guess it's time to do that. Thanks for the links.
Ah, I see now what you meant with constant locking. I interpreted your words as "constant" as in happening all the time as would be the case with fine grained locks instead of one long-lasting, global lock.
With PyPy the performance will get better, and they also have a GC, so that hinder is removed. I don't really know if PyPy has a GIL, I would guess that they don't.
I don't think it would. If there is a GIL (Global Interpreter Lock) only one thread of the process can be scheduled to run at any time. As the poster (Sturla) says, Python threads are native OS threads so they should be scheduled by the OS kernel (right?). A good scheduler would use affinity scheduling and schedule all threads of the Python program on the same processor/core every time to get benefits from cached data and code. I believe modern kernels (Linux, MacOS, Solaris, probably Windows as well) use this kind of affinity scheduling, so if we're lucky the Python process gets scheduled on the same processor every time and there will be no need any cache synchronization.
> I'm not a hardware expert, but I'm not sure how constant locking would prevent cache synchronization just because they weren't truly running in parallel.
I'm not sure if you misunderstood the mail. The constant locking would only be used if they were running in parallel.
Anyway, if you have a GIL you don't need that kind of locking described in the mail. You only need to do explicit locking on shared data structures when you read or update the contents of those data structures. If you have reference counting, threads that run in parallel and no GIL you would have to lock even if you are just assigning a reference to such a data structure to a new variable. If you have a GIL you are certain that only one thread at a time are updating the reference count. That is indeed what the GIL is, one coarse lock for all data (and the interpreter) instead of fine grained locks for every data structure.
(I don't know Python very well, I just answer from general knowledge of computer architecture and language implementation. But I've read about the Python GIL several times, since it's the most discussed GIL of any language.)
I clicked around a little bit at Berkeley's site and found this: http://webcast.berkeley.edu/playlist#c,s,All,3E89002AA9B9879...
It's looks like it should be the lectures you watched.
I also appreciate that you have chosen to publish your writing more in a blog format just like on http://weblog.raganwald.com instead of the GitHub experiment, I never really got into reading your stuff there.
As for the question posed, I believe I'm biased towards invention. I would prefer to work in a research department in a company or in a small company that have a business idea (partly) based on research. I hope I'm wise enough to avoid NIH, that is not really inventing anyway, so it's not as much fun as real inventing. (Working in a university seems to come with too much bureaucracy for my taste, but I do like the teaching part.)
I think Perl and Python have a lot more in common than differences when it comes to what they are good at. If you know one scripting language, you don't gain as much when you learn the next. My recommendation is to learn something different, C, Haskell, Lisp or Prolog for example. That would make you think in different ways.
Also, chromatic (a Perl developer) gives a very balanced answer in a sibling to my answer, so I won't repeat what he said.
I would prefer to use Perl over bash/awk/sed since Perl is good at the same things and more and has alot more libraries.