"You have 59 posts and 103 drafts", says WordPress, and I guess it's right. SELECT COUNT() FROM table" doesn't lie, and then I've always had about 2 unpublished drafts per published post.
Let's try this: I'll give you this list of drafts and you'll tell me which of these you want me to write. I have a bunch, they're all fresh enough for me to still want to write them – I still remember what I meant to say – but help me prioritize.
So, here goes:
- FPGAs vs cellular automata: cellular automata are one example of trying to model computation using local rules, "because the laws of nature are local" or what-not. But real life is not like a game of life, and long wires are everywhere – from long axons to the trans-Atlantic cables we humans laid out right after learning how to do so. I'd write about how FPGAs, which are popular with people who like "locality" and "big flexible computing grids" and other such ideas, support complicated routing and not just simple connections to neighbors. (Which is why FPGAs are a real platform and not a pipe dream.)
- Mircoarchitecture vs macroarchitecture. I love this one, because it sounds like a somewhat original or at least not a very widely appreciated idea. Basically in hardware, there are two different ways to attack problems. Examples of micro vs macro are: out-of-order versus VLIW; SIMT vs SIMD; hardware prefetchers vs DMA engines; caches vs explicitly managed local memories; and software-driven processors vs FPGAs. Basically it's an implicit vs explicit thing – you can make hardware that cleverly solves the problem in a way which is opaque to software, or you can expose "bare" resources that software can manage in order to solve the problem itself. There are a whole lot of implications which I think aren't obvious, at least as a whole and perhaps separately – for example, one approach is friendlier to context switching than the other. This could be a good read for someone on a small team designing hardware – I could convince him to do macro and accept the drawbacks; micro is for Intel.
- Efficiency: shortcuts and highways. To get from A to B, you travel less – that's a shortcut – or travel more simply – that's a highway. (Highways are necessarily "simpler" than other paths – wider, straighter, less junctions – and they're expensive to build, so not every path can be a highway.) It appears to be a good metaphor for optimization and accelerator hardware, in many ways. For example, getting to the highway can be a bottleneck – similarly, transferring and organizing data for accelerators/optimized functions. There are other similarities. This should, in particular, be a nice read for someone good at algorithmic optimization (shortcuts) who is curious about "brute force" optimization (highways).
- "Don't just blame the author of this manual" – this is a quote from an actual manual that I like; the context is that the manual bluntly tells why a feature may likely do something different from what you think it does, and what you should do about it. Basically this spec is outrageous if you think of it as a contract – not much is promised to you - but very good as communication – you understand exactly what the designers were doing and what to expect as a result. The distinction between "specs as contracts" and "specs as communication" is an interesting one in general.
- Leibnitz management: I mention "the best of all possible worlds" together with the efficient market hypothesis, which is what some ways of putting the "efficiency" argument on its head remind me of. For instance, the market is efficient and therefore, if we spend $1M on software or equipment, they must be worth the money (the option of us being suckers and the vendor being sustained by suckers is ignored). Similarly, if you propose an improvement, you're told that it's not going to work since if it did, others would have done it already because of said "efficiency". And other similar notions, all popular with management.
- "No rules" is a rule, and not a simple one: I guess I don't like rules, so I tend to think we should have less of them. It recently occurred to me that what we'd really want is not less rules but simpler rules and that it's not the same thing. For example, if you have no rules about noise, then one has a right to make noise (good) but no right for silence (bad), which is a trade-off that some like and others don't – but on top of that, it creates ugly complications so isn't a simplification compared to having a rule against noise (for example, I can make noise near your property to devalue it). Similarly, giving someone "a right to configure" takes someone else's "right to certainty" – be it config files or different device screen sizes or whatever – also a trade-off. Someone's right to check in code without tests takes someone else's right to count on checked-out code to work. Someone's right to pass parameters of any type takes someone else's right to count on things being of a certain type. So, not only choosing the rules, but choosing the amount of rules is a hairy trade-off. Which goes against of my intuition that "less rules is good" , all else being equal.
- Does correctness result from design or testing? – two claims. 1: correctness always results from testing, never from design; if it wasn't tested, it doesn't work, and moreover, contains some sort of "conceptual" flaw and not just a typo. 2: however, the very property of testability always results from sound design. If it's sufficiently badly designed, no amount of testing can salvage it, because good testing is whitebox testing or at least "gray box" testing and bad design is impenetrable to the mind, so it's a black box.
- Testing is parallelizable, analysis isn't – a complementary idea (perhaps I'd merge them). Suppose you have $10M to throw at "quality" – finding bugs. You could massively test your program, or you could thoroughly analyze it – formal proofs or human proofreading or something. Testing you can parallelize: you can buy hardware, hire QA people and so on. The insight is that you can't really parallelize analysis: to even tell that two parts can be analyzed separately, a lot of analysis is required, and then frequently things truly can't be analyzed separately, because if you understand the fact that listing a huge directory is horribly slow on your filesystem, this understanding is worthless in isolation from the fact that some piece of your software creates huge directories. So analysis can't happen fast even if you're willing to pay money – you have to pay in time. Two things follow: when something is shipped fast and works, we can conclude that it's made to work through testing and not analysis; and, pushing for testing is characteristic of the private/commercial sector where money is cheaper, whereas pushing for analysis is characteristic of the public/academic sector where time is cheaper.
- Buying code takes more knowledge then building it - because when you build it yourself, you can afford to acquire much of the knowledge as you go, but when you're making a purchasing decision and you lack some of the required knowledge, then you'll buy the wrong thing and will then acquire the knowledge through having things not work – much too late. I'd give A LOT of real-life examples from my own real life; it's quite the problem, I believe. (There's frequently no way around buying code, especially if you're making hardware, but I think it's still an interesting angle on "buy vs build".)
- Make your code serial and your data scalar: I claim that things that don't work that way are not debuggable and most people have a hard time with them. For example, type systems (C++, Haskell, Scala, even CLOS), vector languages (APL, Matlab before they had a fast for loop), Prolog (even though I think solvers are a great idea), Makefiles (even though I think DSLs are a great idea), lazy evaluation (Haskell).
There's more but let's see what about these.
117 comments ↓
Top 2 preferences:
1. FPGAs vs cellular automata
2. Mircoarchitecture vs macroarchitecture
I'd like to see the first two as well – they're things I've thought about in the past and I'm interested to see what your take on them is.
In order…
1. Microarchitecture vs. macroarchitecture
2. "Don't just blame the author of this manual"
3. Efficiency: Shortcuts and highways
4. Make your code serial and your data scalar
+1 for "Leibnitz management" and another for "buying code..".
WRT "simple" rules, I think about similar matters in terms of adding strong invariants — if checkins are conditional on tests passing, then the passing test are an invariant. A related direction in programming would be avoiding inheritance or any other kind of type dispatching. Or having a rule of only putting locks in variables / attrs that have 'lock' in their name and 'evt' for events, so you can find all locks and events in the program with a simple text search.
Setting up voting on Google Moderator could be a good option too.
1) Microarchitecture vs macroarchitecture.
2) Make your code serial and your data scalar.
3) Correctness and testing.
Thank you very much, by the way, both for your great writing and your willingness to please!
1. Buy vs build
2. Simple rules
microarchitecture vs macroarchitecture
buy vs build
1. Mircoarchitecture vs macroarchitecture
2. Buying code takes more knowledge then building it – I like real life examples.
3. Make your code serial and your data scalar – Mainly because I don't understand your description, and that makes me curious.
FPGAs vs cellular automata for informativeness
Leibnitz management for sheer spite
* “Don’t just blame the author of this manual”
* Buying code takes more knowledge then building it
* “No rules” is a rule, and not a simple one
All of the above :P
Probably "Make your code serial and your data scalar" the most.
first two over the rest
Really curious about the FPGAs.
I will read all of them. But these are the ones I am specifically interested in – in this order:
Make your code serial and your data scalar
Efficiency: shortcuts and highways
Mircoarchitecture vs macroarchitecture
“Don’t just blame the author of this manual”
Leibnitz management
FPGAs vs cellular automata
No rules vs. simple rules. It's the only description I read all the way through, so that shows you how much it held my interest. :)
1. Simple rules.
2. Serial code, scalar data.
3. Leibniz (no t).
4. Micro vs macro.
I would like to read all of them. I especially want to read stories about ways things fail in your experience (re: testing, haskell, buying code, etc.)
Thanks for your responses, and in particular, it's nice to know that hardware is a popular topic (though I always wonder whether my writing about that stuff gets too detailed or instead too incomprehensible, because I never know what is obvious and widely known and what is obscure in these areas.)
Blame the manual: is this an argument for there being a decent amount of explanatory rationale in a spec?
No rules vs simple rules: this is just the liberal dilemma, balancing rights and responsibilities, fairness and freedom.
Buying vs building and serial + scalar sound interesting.
Efficiency: shortcuts and highways
“Don’t just blame the author of this manual”
“No rules” is a rule, and not a simple one
I am especially curious about
1. Mircoarchitecture vs macroarchitecture.
2. Make your code serial and your data scalar
because the first is a thing I am always musing about, and the second because I wonder if you actually mean "obfuscated", i.e. implicit, structure and what you would do about it.
But I will surely read any of the proposed articles.
I second Marshall's choice.
To encourage you I shall confess I have found your blog a must-read for undergrad students, having been one myself.
I would really like to hear your argument for serial code and scalar data.
Someone I respect very much once said, "You can't test quality into a product."
Therefore, I vote for "Does correctness result from design or testing?"
My bias might be showing. I'm curious what your position is (I would love it if you took a hard stand in one camp or the other, regardless of which one. Guarantee you'll get strong opinions on both sides, watch out reddit.)
Buying vs. Building code is a real conundrum. Would like to read your thoughts about it.
micro vs macro sounds very good
1. FPGAs vs cellular automata
2. Mircoarchitecture vs macroarchitecture
"I always wonder whether my writing about that stuff gets too detailed or instead too incomprehensible, because I never know what is obvious and widely known and what is obscure in these areas."
Another example of where does one erect barriers, in this case to detail or you might end up explaining how a transistor works.
+1 for "Make your code serial and your data scalar"
code serial and data scalar please
FPGAs vs cellular automata
Mircoarchitecture vs macroarchitecture
Make your code serial and your data scalar
Design v. Testing sounds interesting, although I think I'm outvoted here.
My top three:
1) "Don’t just blame the author of this manual"
2) “No rules” is a rule, and not a simple one
3) Buying code takes more knowledge then building it
1) Make your code serial and your data scalar
2) “Don’t just blame the author of this manual”
…but I too would read any of them
1) Micro vs. Macro
2) Make your code serial and your data scalar
Serial code, scalar data.
I really like reading your blog and would happily read all of these. Giving a priority to the list of options, it would be approximately:
1) Testing is parallelizable, analysis isn’t.
2) Does correctness result from design or testing?
3) Make your code serial and your data scalar.
4) Efficiency: shortcuts and highways
5) Mircoarchitecture vs macroarchitecture.
6) “No rules” is a rule, and not a simple one.
7) FPGAs vs cellular automata.
8) “Don’t just blame the author of this manual”.
9) Buying code takes more knowledge then building it.
10) Leibnitz management.
Thanks for all the hard work!
Buy vs. Build
Correctness from design or testing
1. Buying code takes more knowledge then building it
2. Testing is parallelizable, analysis isn’t
Thanks again for your votes; I'm currently working on macro vs micro which seems very popular – it's coming out long, I might split it into parts perhaps.
Make your code serial and your data scalar, please!
A late vote for: "Make your code serial and your data scalar."
Perhaps after macro vs. micro?
Another late vote:
In case you decide to complete another draft, I'd love to see "Efficiency: shortcuts and highways"
I am dying to know what serial code is and how to pack everything in scalar data.
I simply must tell you that you have an excellent and unique post that I kinda enjoyed reading.
Some truly good content on this web site , appreciate it for contribution.
Good, this is what I was searching for in bing
In my view, yosefk.com does a great job of dealing with subjects of this type. While ofttimes deliberately contentious, the material posted is more often than not well-written and challenging.
I conceive you have mentioned some very interesting details , appreciate it for the post.
very cool post, i actually love this web site, carry on it
I like this page, useful stuff on here : D.
Your article has proven useful to me.
I truly enjoy looking through on this web site , it holds superb content .
Enjoyed examining this, very good stuff, thanks .
Ha, here from google, this is what i was searching for.
Enjoyed reading through this, very good stuff, thankyou .
very Great post, i actually enjoyed this web site, carry on it
Thanks for this post. I definitely agree with what you are saying.
This is amazing!
I simply must tell you that you have an excellent and unique article that I really enjoyed reading.
Enjoyed reading through this, very good stuff, thankyou .
Cheers, great stuff, Me enjoying.
Enjoyed examining this, very good stuff, thanks .
I conceive you have mentioned some very interesting details , appreciate it for the post.
I like this website its a master peace ! Glad I found this on google .
Cheers, great stuff, I enjoying.
I like, will read more. Thanks!
Your web has proven useful to me.
Cheers, great stuff, Me like.
I am glad to be one of the visitors on this great website (:, appreciate it for posting .
yahoo took me here. Thanks!
I enjoying, will read more. Cheers!
I am glad to be one of the visitors on this great website (:, appreciate it for posting .
Just wanna input on few general things, The website layout is perfect, the articles is very superb : D.
Enjoyed examining this, very good stuff, thanks .
Some truly fine content on this web site , appreciate it for contribution.
bing took me here. Cheers!
I like this site because so much useful stuff on here : D.
I really enjoy examining on this website , it has got good goodies .
You got yourself a new follower.
Me enjoying, will read more. Thanks!
Appreciate the website– extremely user-friendly and lots to see!
6/7/2019 In my opinion, yosefk.com does a excellent job of dealing with topics of this kind! While sometimes deliberately controversial, the posts are more often than not well-written and stimulating.
Great, yahoo took me stright here. thanks btw for info. Cheers!
I am not rattling great with English but I get hold this really easygoing to read .
I must say got into this site. I found it to be interesting and loaded with unique points of interest.
Thank You for this.
Just wanna input on few general things, The website layout is perfect, the articles is very superb : D.
I like this website its a master peace ! Glad I found this on google .
I consider something really special in this site.
Deference to op , some superb selective information .
Thank You for this.
Good Morning, yahoo lead me here, keep up great work.
Deference to op , some superb selective information .
Great, google took me stright here. thanks btw for post. Cheers!
yahoo got me here. Cheers!
I like this site because so much useful stuff on here : D.
I simply must tell you that you have an excellent and unique post that I must say enjoyed reading.
google brought me here. Cheers!
stays on topic and states valid points. Thank you.
Some truly interesting posts on this web site , appreciate it for contribution.
Enjoyed reading through this, very good stuff, thankyou .
I dugg some of you post as I thought they were very beneficial invaluable
Respect to website author , some wonderful entropy.
Parasite backlink SEO works well :)
Enjoyed reading through this, very good stuff, thankyou .
I kinda got into this web. I found it to be interesting and loaded with unique points of interest.
Appreciate it for this howling post, I am glad I observed this internet site on yahoo.
I really enjoy examining on this website , it has got interesting article .
Intresting, will come back here more often.
Just wanna input on few general things, The website layout is perfect, the articles is very superb : D.
Thank You for this.
I simply must tell you that you have an excellent and unique article that I really enjoyed reading.
Comprar Viagra Contrareembolso Zaragoza Viagra Sin Receta Foro [url=http://ilfrc.com]viagra que pasa[/url] Cialis From Canada
I love reading through and I believe this website got some genuinely utilitarian stuff on it! .
I’m impressed, I have to admit. Genuinely rarely should i encounter a weblog that’s both educative and entertaining, and let me tell you, you may have hit the nail about the head. Your idea is outstanding; the problem is an element that insufficient persons are speaking intelligently about. I am delighted we came across this during my look for something with this.
Your article has proven useful to me.
bing brought me here. Thanks!