Cool! I'm really curious about what you're up to since I'm doing something similar. Mine's up at https://www.onlyvetted.com/
Hit me up at kevmod at gmail, would love to hear more.
3,205 karma · joined July 24, 2009
Hit me up at kevmod at gmail, would love to hear more.
It's designed to analyze and optimize existing codebases. So far it's produced some pretty decent speedups on the Python interpreter, though with a big drawback of very high compilation times due to using LLVM.
Let me know what you think or if you have performance-sensitive programs that you think would benefit from a low-investment JIT.
- Can every minesweeper board be solved without guessing?
No:
1 ?
1 ?
Yes. Just enumerate all combinations of mine/not-mine for every hidden cell, and look at all the boards that match the exposed clues. If there is a square that is never a mine, click it. If there isn't, the board requires guessing.
- Is there an efficient algorithm to do the above?
Most likely not. Minesweeper as a decision problem ("is there any solution to these given clues") is NP-complete. http://simon.bailey.at/random/kaye.minesweeper.pdf
Programmable logic circuits are presented as hardware libraries called overlays. These overlays are analogous to software libraries. A software engineer can select the overlay that best matches their application. The overlay can be accessed through an application programming interface (API). Creating a new overlay still requires engineers with expertise in designing programmable logic circuits.
You might say "why doesn't this exist already", but the whole ecosystem is currently quite hard to use (think GPU programming but from 5 or 10 years ago) so putting some nice interfaces on it could be a big step. Will be interesting to watch.
I did a quick search for who male Programmers, Executives, and Janitors marry (tried to pick a diverse set), and then filtered out the top five female occupations in this data (Teachers, Assistants, Nurses, Misc Managers, Salespersons). The remaining results were: male Programmers marry female Programmers, male Executives marry female Executives, male Janitors marry female Janitors or female Maids.
So I whipped up a script that, instead of measuring the absolute frequency, normalizes the data set against how often the target occupation gets married to. ie instead of just counting common pairings, it measures "how much more likely is profession X (compared to the general population) to marry profession Y?".
For male CEOs, the result is: they marry other CEOs. Male CEOs are 12x more likely to marry a female CEO than males in other professions are. They are also 12.6x more likely to marry embalmers! 7x more likely to marry Announcers, 5.3x more likely to marry "Dancers and Choreographers", and 4.9x more likely to marry "Public Relations and Fundraising Managers". They are only 1.2x more likely to marry a Secretary than other males are.
For male programmers, it is similar: male programmers are 20x more likely to marry female programmers than other male occupations are. This is because only 0.2% of men marry female computer programmers, but 3.4% of male programmers do. Male programmers also marry female Materials Engineers (20x more likely), Information Security Analysts (13x), "Surveyors, Cartographers, and Photogrammetrists" (10x), and "Architects, Except Naval" (8x).
I also picked one final way of slicing it: "how many more of these marriages did we see than expected" (expected based on the relation frequencies of the two occupations). This is another way of removing "well we would expect a lot of these marriages", but in a way that is less geared towards low-occurrence matches like CEO-Embalmer. For CEOs, the results are: CEOs, Misc Managers, Elementary and Middle School Teachers, Secretaries, Accountants and Auditors. For Programmers, it's: Programmers, Misc Managers, Other Teachers and Instructors, Software Developers, Accountants and Auditors.
Anyway, this isn't to say that these other ways of looking at the data are any "better", they're just answers to different questions.
I threw up the code in a gist -- sorry it's messy https://gist.github.com/kmod/ee6ac3c029641b39d0b6
One particular point is Python subclasses: it makes a lot of sense to say that a Python subclass is a subtype of the parent class, but in reality there are no guarantees about any relationship. This means that a compiler/VM would most likely have a hard time making use of type annotations since it would have to have to support the user passing arbitrary subclasses with completely different behavior.
Guido advises but isn't actively involved.
I think you can look at the people who are interested in adding LLVM tiers to their JITs (ex Apple, Facebook) to see that we're not the only ones that think there can be a place for "good but expensive" code generation in a JIT.
You're definitely right, Python has a lot of user-customizability that can make it harder to execute efficiently than JavaScript (though thankfully it has less than Ruby). Both PyPy and Pyston have their techniques for cutting through the complicated+expensive slow case and trying to predict and execute a fast path.
This kind of mathematically unsophisticated reasoning is exactly why Benford's law is so surprising to people. If you think of what it means for a value to be "truly random", the result is not surprising at all.
These new models have dual-core atoms, which will help, but mostly it's just the awful single-core performance that gets you. Even tying emails in gmail was an extremely painful experience; often the characters on the screen would lag significantly behind my tying, and it would take forever to load the different pages.
I don't think anyone is arguing that you can use these things for "real work". I'm going to argue that if you care about your time, you can't even use these things for any of the other stuff they advertise. Unless the new processors are significantly better, I'd say get something else.
For the criticism that the project will "fail", I think there's some merit. Will this produce the next computation system that the world uses? Probably not. Will this push the boundaries of engineering and improve on the state of the art? Almost certainly. And due to its scale, and the fact that Angstrom was created by combining multiple separate projects, there's also room for individual projects or ideas to succeed even if others don't.
My background is that I worked on the FOS project, which is the part that is most related to the title of this post. If you were looking for more technical meat, I encourage you to check out the project page: http://groups.csail.mit.edu/carbon/?page_id=39
The conclusion that BB/BG/GB are all equally likely follows from the assumption that the man would definitely state that he has a male child if and only if one of those conditions were true. But what if instead we add the fact that the man would only say that he has a son if he has no daughters? This isn't contradictory with anything else in the problem, but now the answer is clearly "P(BB) = 1", which makes it hard to state that certainly "P(BB) = 1/3" when there is a consistent interpretation of the problem that gives a different answer.
You should reread the way he set up the problem again: he makes the subtle distinction between things that are given to us by the omniscient problem writer and things that are given to us by characters inside the problem, for whom we have to apply Bayes Law an additional time.
- The difference in performance is too big to be a memory bus issue
- Since the number of threads doesn't change, just the number of processes, it's not an un-scalability issue of the program.
- It's most likely not a issue with which CPUs he chose; in a hyperthreaded system there can be a pretty large performance hit if he pinned the server to logical cpus that were on the same core. I don't know how Intel numbers its cores in hyperthreaded processors, but their general method is "make the cores that are closest to each other have the biggest difference in cpu ids", which would mean that ex cpus 1 and 5 are on the same core.
- I would guess that it's not a thread migration issue, since I wouldn't expect the Linux scheduler to be that bad.
Poor cache performance is the most likely cause. As a minimal example of what the author concludes, if you have two threads that sit in a loop incrementing the same counter, it is much faster to run those two threads on the same cpu than on their own cpus. This is because when running on separate cpus, that particular cache line will continually be ping-pong'ed between the two. Even if threads don't access the same addresses, if they access addresses that are in the same cache line, you'll still get ping-ponging ("false sharing"). This explanation is also supported by the fact that it disappears on i7 processors; one of the largest improvements with the Nehalem line is the improved cache architecture.
Poor cache behavior is usually the culprit in non-cpu-bound and non-io-bound systems.
- Get a bunch of well-respected people together
- Create something exciting
- Use your connections to find people that you know are good