tmurray · HackerTrans

tmurray

no profile record

comments

hace 6 añosdiscuss

they're not a userspace construct in any meaningful way. libutils/Thread (capital-T Thread) is a thin wrapper around pthread_t, and most Android code uses pthread_t directly. what this hit is probably a bug related to timerslack_ns--there's some code to tweak timerslack values on a per-thread basis instead of a per-process basis even though audio should never be coming from processes low enough on the importance list to get a high timerslack value--but L bugs fixed in M are before my time.

hace 11 añosdiscuss

GPUs don't have a page fault handler; when there's a page fault, it's an unrecoverable crash. Accordingly, zero-on-allocate (or potentially zero-on-free, but that makes assumptions about startup and teardown that may not be true) is the only way to do it.

hace 11 añosdiscuss

X1 is actually the 64-bit ARM CPU configuration (Cortex A53 + Cortex A57), not Denver. K1, the predecessor of X1, comes in two flavors: 32-bit 4xCortex A15 and 64-bit 2xDenver. TK1 is 32-bit, Nexus 9 is 64-bit (and is the only device I know of with Denver).

hace 11 añosdiscuss

property taxes are capped in CA, so the landlord's costs are essentially fixed: http://en.wikipedia.org/wiki/California_Proposition_13_%2819...

hace 12 añosdiscuss

I actually read IJ on a Kindle and found it significantly easier for the most part than reading it in print because of links to endnotes, which removed the requirement to keep two sets of bookmarks (if you haven't read it, some endnotes in IJ are a sentence are two, some are 40 pages). There were some occasional issues with going back to the main text (IIRC the back button's stack wasn't saved across sleep), but overall it was much better for me.

But no, I'd never read a textbook on a Kindle. Can't flip around.

hace 12 añosdiscuss

GPUs don't support precise exceptions. For example, you can't take a GPU program that contains a segfault, run it as a standard program (as in, not in a debug mode), and be presented with the exact instruction that generated the fault.

hace 12 añosdiscuss

https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/Function-Attrib... and http://pasky.or.cz/dev/glibc/ifunc.c

look up the target attribute and the ifunc attribute--it's basically a way to compile multiple versions of a function for different targets in a single source file and then use the dynamic linker to determine which one to resolve at runtime. obvious use is for things like optimized memcpy implementations.

hace 12 añosdiscuss

but that's GLES 2.0, which is significantly less flexible than the kinds of GPUs we're discussing here and is not even in the same ballpark as a CPU (and almost certainly significantly less strict in terms of floating point precision than a GLES 3 device).

hace 12 añosdiscuss

disclaimer: I work in this space and have done so for a while, including previously on CUDA and on Titan.

GPUs for general purpose computation were never 100x faster than CPUs like people claimed in 2008 or so. They're just not. That was basically NV marketing mixed with a lot of people publishing some pretty bad early work on GPUs.

Lots of early papers that fanned GPU hype followed the same basic form: "We have this standard algorithm, we tested it on a single CPU core with minimal optimizations and no SIMD (or maybe some terrible MATLAB code with zero optimization), we tested a heavily optimized GPU version, and look the GPU version is faster! By the way, we didn't port any of those optimizations back to the CPU version or measure PCIe transfer time to/from the GPU." It was utterly trivial to get any paper into a conference by porting anything to the GPU and reporting a speedup. Most of the GPU related papers from this time were awful. I remember one in particular that claimed a 1000x speedup by timing just the amount of time it took for the kernel launch to the GPU instead of the actual kernel runtime, and somehow nobody (either the authors or the reviewers) realized that this was utterly impossible.

GPUs have more FLOPs and more memory bandwidth in exchange for requiring PCIe and lots of parallel work. if your algorithm needs those more than anything else (like cache), can minimize PCIe transfer time, and handles the whole massive parallelism thing well, then GPUs are a pretty good bet. If you can't, then they're not going to work particularly well.

(now, if you need to do 2D interpolation and can use the texture fetch hardware on the GPU to do it instead of a bunch of arbitrary math... yeah, that's a _huge_ performance increase because you get that interpolation for free from special-purpose hardware. but that's incredibly rare in practice)

hace 12 añosdiscuss

Kayvon teaches at Carnegie Mellon now and his class slides are definitely worth reading:

http://graphics.cs.cmu.edu/courses/15869/fall2014/ http://15418.courses.cs.cmu.edu/spring2014/

hace 12 añosdiscuss

sorry, the desktop Intel SIMD ISAs are generally not something I use on a day-to-day basis, so I get them mixed up a lot. (LRBni was the last one I looked at for any serious length of time.)

hace 12 añosdiscuss

I spent a lot of the past month improving the RenderScript (Android data-parallel compute, using C99 plus vectors) codegen to better work with the LLVM vectorizers, so I have a fair amount of experience with this exact question.

The vector types help in some ways--if you can use only vectors and do arithmetic on entire vectors only the SIMD codegen already works great--but they don't really help more than an intelligent vectorizer could. For example, the LLVM loop vectorizer can only handle loops where the induction variable changes by 1 or -1 each iteration. As a result, you couldn't set A[i], A[i+1], and A[i+2] in a for loop where i += 3 each iteration. If you could do that, you wouldn't really need vec3 in the first place. (also, the presence of any vector types whatsoever prevent any vectorization in LLVM right now, so...)

Another issue is that using vectors for storage and vectors for computation are very different things. I don't think anyone actually likes using vectors for computation, but vectors for storage make a lot of sense in some fields like image processing. However, as soon as you start operating on single channels, things get messy. Let's say you have a for loop where each iteration operates on a float4 as individual channels. Let's also say you want to turn each of those single channel operations into its own float4 operation, vectorizing across four iterations of the loop. Given most current SIMD ISAs, you're going to have to do four 32-bit loads of A[i].x, A[i+1].x, etc., then pack that into a vector, do your arithmetic ops, unpack the vector, and do four 32-bit writes to memory. Unsurprisingly, this is not particularly fast, and if you're doing one mul or FMA per channel, you shouldn't be vectorizing at all. This is why you see cost models in vectorizers (to prevent this sort of packing/unpacking from killing your performance when you enable your vectorizer) as well as why you see newer SIMD ISAs like AVX2 in Haswell including support for scatter/gather and permute.

The last issue is that it's trivial to break a vectorizer because of easy to overlook things like ailasing. Missing a single restrict will prevent vectorization if the compiler can't prove that pointers won't alias, for example (why do you think people still use fortran in HPC?). There's actually been a lot of great work here in LLVM over the past few months with new aliasing metadata for LLVM IR (http://llvm.org/docs/LangRef.html#noalias-and-alias-scope-me...), which is what I used to make the SLP vectorizer work with RenderScript in a way similar to ISPC (except in the compiler back end instead of the front end, because we don't even know the target ISA at the time the RS source is compiled to LLVM IR). I'll probably get the patch in AOSP in the next week or two if you want to keep an eye on that; it needs a newer LLVM version than what shipped in L and we're finishing up that rebase.

(honestly, I think that if you're trying to get good server CPU performance and you know exactly what CPU you're going to be using at compile time, you should be looking at ispc instead of doing SSE intrinsics yourself: https://ispc.github.io/ )

hace 12 añosdiscuss

>> 20 years of legacy, needs a reboot and major simplification pass

This was attempted. It failed: http://en.wikipedia.org/wiki/OpenGL#Longs_Peak_and_OpenGL_3....

hace 13 añosdiscuss

B3D PM is fine.

hace 13 añosdiscuss

I implemented scatter back in October, but it just barely missed Android 4.2. It's in the next release.

hace 13 añosdiscuss

Desktop: high-end consumer GPUs have about 10-15x the single-precision FLOPs and 4-6x the bandwidth of a single Intel CPU socket. At this point, usually connected via PCIe Gen3. There are two real vendors (NVIDIA and AMD), and what comprises a system is generally the same (CPU + some number of GPUs).

Mobile: GPU has 3-5x the FLOPs of the CPU and no bandwidth advantage because of the shared memory pool between CPU and GPU. GPUs have very wide ranges of functionality. Even the CPUs behave very differently (Krait in Nexus 4 sometimes chews through code that the A15 in Nexus 10 chokes on and vice-versa). What comprises a system varies tremendously--CPU, CPU + GPU, CPU + GPU + other processors, etc.

A developer shouldn't be expected to have to tune for 20 different processors and system architectures in order to ship an app on the Android market. That's the problem we're trying to solve, not simply exposing access to GPU compute.

hace 13 añosdiscuss

Pretty much exactly this. Performance portability is our main concern, and we are willing to trade off some peak performance to get it because of how badly you will hurt yourself on different architectures. We are trying to solve low-hanging problems first before attacking more complex algorithms.

hace 13 añosdiscuss

I worked on CUDA at NVIDIA for over four years and was the primary API designer for a large part of that time. I started on RS at Google in September.

Basically, he gives us too little credit for the execution model (it's young, it's improving very quickly and is not at all designed to emulate anything else that exists today) and assumes that GPU compute has the same tradeoffs on mobile as desktop (it doesn't at all). You'll see more from us soon.

hace 14 añosdiscuss

I think it's a political move more than a technical one. WinRT lets MS say to Intel that Intel has to care about the tablet market and low-power processors or otherwise ARM will get a foothold in Windows (giving them easy access to the low-end of the laptop market in the next few years).

Of course, this would have worked a lot better if people cared about WinRT at all, but I'm sure that was the idea.

hace 14 añosdiscuss

They're blade systems, there's not really room for disks. Easier to keep it centralized and easily serviced.