A few things Scott has said have roused my attention and are linked;
In the UK we don't make anything, instead we have fostered an environment for investment banks and the companies that service banking. If you want to earn good money and be involved in mentally demanding projects, there's only one serious option*. I don't
know a bank that doesn't block social networking sites, or doesn't enforce suits.
Employment/Recruitment and Blogs
In my experience, the banks don't spend much time looking at CVs to look at a blog. In a recent interview with a "billy big potatoes" WPF-on-the-tradefloor consultancy, they complained about candidates that don't research stuff mentioned in interview, and
yet when asked, they interviewers hadn't checked my blog and even asked questions that they only knew the answer to because I had highlighted it on MSDN in the comments section.
Even more importantly, recruitment consultants strip out real names and blog information from our resumés!! The situation is ridiculous and is negative for everyone involved.
Lastly, I'm amazed how little there is in the comments sections on MSDN. I make a point of going back to the article and adding something to help prevent other humans feeling the excruciating frustration that I went though to make something work. We blog
about x and get answers on Stackoverflow to y but why aren't we getting that information put on the documentation? The facility is right there. I think its because MS don't push the rewards system enough and so there's no glory in it.
(Scott: great talk as always, keep the humour coming)
*the UK has a big bio-chem and medical base in Cambridge but they tend to draw from their own universities. Maybe we have formula one automotive engineering or Rolls Royce in Derby but in terms of job abundance, the City of London is the only reasonable
go to. (Discuss).
Just extrapolating this, forgive me, but stills from video > Photosynth > point cloud > 3D mesh > automatons with cheap camera eyes > robots that understand their spacial environment in great detail > autopiloted vehicles > world domination.
Seriously, and a little digressively, this and the other work in 3D interpretation of a scene has huge potential in remote control systems and orientation of automated devices. Does NASA have this kind of technology in the Mars rover?
My feedback for the Phone7 product team is: refine, refine, refine. I noticed that touch drags were slightly jumpy and sometimes the gestures were 'missed'. This product has huge potential but it must not suffer a death from a thousand cuts. Perfectionism and
obsessing over details is what made the iPhone.
As I see it, a counting semaphore is a form of throttle. This primitive is not related.
For me, the example code scenario is very familiar and this replaces the array of wait handles that I usually have to maintain when spinning up work items. I must admit to frowning at the 'hack' as it looked easy to forget, and like an after thought. There
could be something like a FinishedAdding() method (just sets an initial handle) just to emphasise the requirement, or maybe not.
Great quality on the recording, on this laptop the fullscreen is like sitting at the machine it was recorded on. Although I'd love to be able to sign-in and comment without interrupting playback. Grrr...
Seva. You are correct, my apologies. Although the problem with using PF dev team stats is that while they may know that cranking up the other threads takes, say, 2,000 cycles per thread (I've really no idea - could be 20,000), you'd still have to test your
task/code to see how much work it is in comparison.
Although if the profiler could try P.For and normal For and suggest when you're actually degrading performance, that'd be excellent. That said, I did think that P.For uses some kind of ramping up technology so it ran synchronously for small loads - and thus,
what we saw in the video shouldn't happen. P.For is so easy to use but so easy to use in the wrong place.
My problem is that most of the code I write I think is too small to be parallelised. Like arrays of 12 items. By the time I've finished I've got a huge chain of little bits of work adding up to a large amount of work, so then I start to look for logic that
can run independently of each other and kick off some branch of execution on another thread and re-join/wait further down. The problem being that in the future I won't be able to find enough simultaneous work to spread across all cores!
As the narrator mentions, the Debug.Writeline causes the threads to queue/block on writing to the log/IDE. If this operation is significantly more costly than the work in the task (he has some simple math) then you're running essentially synchronously and
the parallel code just becomes a burden.
Also, I always test by running the methods thousands or even millions of times and taking an average. OS noise amongst other things can severely impact a single pass of a method so you can sometimes get a misleading result.
Edit -- the tools far exceed all expectations. I'd like to see in-code-editor warnings about compiler optimisation and reordering pitfalls; for example, if I add an attribute [MultiThreaded] to a method, then (after compilation) the IDE highlights execution/reads/writes
that has moved from the order it was coded.
Yup I'm with Odi; develop a couple of longer distance SideSight sensors under the front of the keyboard or something so the 'mouse' is no longer a feature. I'd be happy to drag my thumb around on the desk as the pointer - thinking about it, its not dissimilar
to a large trackpad with Macbook style gestures.
It's true that we will be up for all kinds of RSI injuries if we have to hold our arms up touching an LCD screen all day.