I think you'll have the fewest distribution issues with a go binary. But if you have lots of experience building and distributing java programs to your customers then go with what you know!
Being able to build Go into a binary without any dependency makes distribution really easy. As a user I prefer a single file that I can download and run and as a developer it has really simplified builds and deploys.
agreed. for a user to get a python cli to work they will need to install python and any open source libraries your cli depends on (unless you use some tool to bundle all the dependencies with your app, in ye olden days this was py2exe or similar for bundling for windows).
similarly, for java you place the burden on your users to install a jre
with go the standard build toolchain lets you easily cross-compile a bunch of statically linked binaries, so each user just downloads 1 file for their target platform and runs it.
personally i am much more productive writing code in python than in go (this is largely a consequence of spending 20x as much time writing python than go) but go is dramatically more ergonomic from a deployment perspective and has a great cross-platform library and cross-compiler support out of the box
Neat idea! If a little impersonal. Perhaps adding a personal message field that gets printed on a card and sent along with the package? Theres gotta be a service for that.
It does that! If you make a contribution, you type in your name and a personal message. That gets included later when the order is shipped from amazon.com.
I remember reading a blog post of the peculiarities of GPU programming and the post noting that for most modern graphics cards (at the time) if you can keep your computable data in chunks no bigger than 64kb a piece you can expect to see enormous performance gains even on top of what you'll see by using openCL/CUDA because of a physical memory limit on the actual GPU itself.
I also remember thinking that a 64kb row size for DynamoDB was very odd.
You are taking about shared memory in CUDA, local memory in OpenCL. When you are reading from the same location over and over again (most notable cases are linear algebra functions, filtering in signal processing), reading from DRAM is going to be costly. This is solved on the CPUs by having multiple layers of caches.
Early generation of NVIDIA gpus did not an automatic Caching mechanism or could not for CUDA, I forget) that could help solve this issue. But they did have memory available locally on each compute unit where you could manually read / write data into. This helped reduce the overall read/write overhead.
Even when the newer generations have the caches, it is beneficial to use this shared / local memory. Even when the shared / local memory limits are hit, there are alternatives like Textures in CUDA, Images in OpenCL that are slightly slower, but significantly better than reading from DRAM.
That's interesting. I know a lot of web designers that use macs primarily and I wonder how having such a high default resolution would impact their design choices. Could this 'break the web' as people around here are so fond of saying for non high resolution screen users?
I doubt that the new macs will have higher effective resolutions. Everything will be very sharp but will remain the same size, just like on the iPhone. This can't break the web, it will simply raise the ceiling on how good a website can look.
Except that designers might want to include 4x-sized bitmap assets to have their sites appear sharp on those retina displays. If that isn't done carefully, users with smaller displays might have to download those, wasting their bandwidth.
