lgeek

I'm with you on this one. After seeing this running at 15-20 fps, my reaction was that web technologies have finally been shoehorned in a place where they can almost provide the same experience as 15 year old native games, while running on a modern machine. Oh well, the 'hardware is fast, overhead doesn't matter' crowd doesn't care.

> Zeroed memory should not be particularly expensive on modern machines, because we have a lot of parallelism available to zero it off working threads.

It must be nice living a world where energy is free, you have unlimited cores and unbounded caches, and context switches, thread synchronisation and cache coherence have no cost or latency.

I'm not saying that reducing the number of cases with undefined behaviour isn't worth it in most cases, but claiming that you can just zero application memory at virtually no cost on a multicore is misguided.

Many of the capabilities described in the article are just hardware features which don't need any control from application developers, but their effectiveness can be improved if the developers are aware of them (e.g. caches, TLBs). Others properties are exploited automatically by compilers (e.g. instruction scheduling for improving throughput in a superscalar processor)

Instruction set extensions (which I believe might be what you were thinking of) are used via intrinsics and assembly programming by pretty much any performance-oriented code. For example look at the dozens of architecture-specific implementations of glibc functions: x86-64[0], arm[1].

[0] https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/x86... [1] https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/arm...

The added electronics just rest against the adapter's boards: http://samy.pl/keysweeper/testingsize.jpg. This looks quite unsafe because of reduced clearances. It has a chance of either exposing HV on the LV (USB power) side or shorting the various boards, potentially starting a fire.

It's a pretty cool proof-of-concept, but I wouldn't connect anything to the USB port. These issues could be solved for deployment by potting or by using a custom smaller PCB integrating the various boards.

If you can set a chromebook to developer mode, it's quite simple to then sign your own images containing either another bootloader or a custom kernel. The only annoyance from my point of view is that vboot images don't seem to support an initrd.

Chromebooks can also run ChromeOS in a window on GNU/Linux* , which is rather more useful for ocassional Netflixing mixed with more productive use.

* probably a violation of the EULA

They have a GSM network too: http://events.ccc.de/congress/2014/wiki/Static:GSM

I haven't used Radxa SBCs, but I did some development for RK3188 GNU/Linux support half an year ago. At the time the hardware video encoders and decoders were not supported on GNU/Linux, but worked ok on Android (with libstagefright support I think).

I've added XV support[0] for video resizing and colorspace conversion, after which mplayer compiled with NEON support and with multithreading could decode in software pretty much any video I've thrown at it.

Things could have significantly improved since then, but I've been out of the loop.

However, I would strongly recommend just going for a Jetson-TK1 - I happen to be posting this from one. You get a fairly comprehensive reference manual and NVIDIA fully supports GNU/Linux (albeit with proprietary Xorg drivers at the time), the ARM cores (Cortex-A15 @ 2.3GHz) are much faster, the GPU supports full OpenGL (as opposed to OpenGL ES) and NVIDIA and the community are working on a fully open source driver stack (with nouveau).

[0] https://github.com/lgeek/xf86-video-fbturbo - very much abandoned alpha-quality software

However, mmap and the functions which rely on it will return MAP_FAILED/NULL if no gap large enough is found in the virtual address space or if you've used MAP_FIXED and the area isn't free. If you don't check for errors, the application could potentially end up trying to dereference a NULL pointer.

On the systems I've seen, brk makes a lazy allocation, i.e. it doesn't allocate physical memory until you write to a page.

Yeah, you were right. I've checked and it seems the GCC version I'm using is inlining memcpy calls if it can statically determine the size argument and if the size is lower or equal to 64 bytes.

What compilers are you thinking about? I've never seen GCC inlining and specializing a call to memcpy, it just calls the generic (but optimized) implementation in the standard library.

> Has a simple mapping to the underlying hardware? That stopped being true three decades ago.

I've seen this claim repeated a few times in the thread and I still have no idea what it means.

For medium levels of optimisation it's usually very simple to predict what assembly code will be generated by C compilers. On many platforms the operators often match directly to a instruction (e.g. arithmetic and bitwise operations) or short patterns of instructions (the control flow primitives and conditional execution, equality testing, function calling, etc). At a higher level, compiled C functions look pretty much exactly like manually written assembly language procedures and structs are just blocks of memory with clear order and offsets. It's also very simple to interface C and assembly code without any hacks on either side.

Not ewww, it's one of the more interesting developments (well, technically a revival) in computer architecture from the industry. I just wish they'd 1) document their architecture and 2) allow access third party access to the bare metal.

It's virtual addressing, the loader maps the image at whatever address is specified (with some restrictions).

The 64-bit Tegra K1 doesn't run ARMv8 code natively. It's a proprietary VLIW architecture with an undocumented (AFAIK) ISA. It executes ARMv8 using a firmware-level dynamic binary translator, similarly to how Transmeta processors were running x86 code.

Even if the JTAG pins are brought out, the hardware is a proprietary NVIDIA architecture, you wouldn't have any development tools for it. I suppose they might use the DBT firmware to allow direct debugging of the ARM code, but I don't think it's very likely.

Link at the correct address so there's 1MB between the end of the application image and the bottom of the stack. Allow the linker to load the shared libraries (or just link statically) and then use mmap to fill the rest of the virtual address space. You can implement this in multiple ways.

It's a bit of a weird exercise, you'd generally just calculate the maximum space used by the algorithm, maybe account for stack frame size if recursion is used.

> Its a symptom of doing really ugly things with the stack

Yes, that's spaghetti code. In general I strongly recommended to write assembly functions which follow the platform's ABI (I'm a TA for a course using assembly programming). At the very least, function calls and returning values should be consistent and function calls shouldn't have this kind of side effects. In this case

* calculateStrLength effectively leaks stack space because it pushes the input string and doesn't balance the stack before returning - this is why the return value is passed using rdi. At least the return value pushed by call could have been preserved in calculateStrLength itself. It also increments the size counter without resetting it (it's reset to 0 in _start) which is a bit of a weird choice.

* then reverseStr (which is not a function but just a label in _start) pops the string off the stack and copies it to the OUTPUT buffer (but doesn't copy an end of string NULL character - which works because the buffer is in the bss section, but it's not a good practice). The return address pushed by the call to calculateStrLength is left on the stack.

The whole thing is designed pretty weirdly because reversing a string is trivial to do in place (or with just an input and output buffer), there's no need to use the stack.

It may be the same in the sense that hypervisors don't explicitly limit it, but on a multicore host you're sharing memory bandwidth with the other guests, in the common(?) case when the host has more cores than a guest. You can also experience increased latency when there is access contention.

Linking order will affect code and static data order and cache alignment in turn. Similarly, environment variables are pushed on the stack by the kernel. Their size will affect alignment of application data on the stack.

Maybe there are other causes as well.

> Would it be possible to determine ahead of time what order would maximize performance, or would that require profiling?

I think at the very least, you'd need profiling to determine the hot code path, and that can change depending on input...

For prototyping you can also solder BGAs with any hot air rework station. Even if you don't already have one, Atten 858D only costs around $60. Here's an example (not my video): https://www.youtube.com/watch?v=L8EWqWj2srg

I think it's using the analog audio hardware, similarly to this project.

I would suggest reading the jemalloc paper [0]. The main improvements compared to phkmalloc are:

* improved cache locality

* reduced false sharing

* use of multiple arenas for reduced lock contention

[O] http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemall...

I really doubt there's any data size for which sort + binary search is going to be faster than linear search. The former has higher complexity (so it's going to be slower for large inputs) and more expensive operations (so it will be slower for small inputs).

You can also think about it as a sort of reductio ad absurdum: Assume that the array is actually already sorted and you use a sorting algorithm with O(n) complexity for already sorted data. In this ideal case you'd need to do n (for sorting) + log n (binary search) predictable operations. For linear search you'd only need to n operations of the same type. In practice you'd need to do n log n operations for sorting, I don't think you can avoid unpredictable branches, and instead of just loading elements sometimes you'll move them around.

It's been a while since I've used it and it turns out it's a first generation Samsung Chromebook (XE303). I don't remember having any WiFi-related issues.

The source code used to build the kernel for ChromeOS should be available so I'm surprised this sort of thing is a problem.

You can boot your own kernel directly to a GNU/Linux rootfs. If you need more space, high speed SD cards work quite nicely.

Tianocore EDK2, which they plan on using, is the reference UEFI implementation and is BSD-licensed. ARM actually develops and maintains the ARM-specific parts of the implementation.

There's very little ARM hardware in a laptop form factor in general, none of it is ARM64, and the ones that exist are mostly chromebooks, so maybe not the best build quality.

> Apple, Samsung, and Qualcomm have locked up the handheld arena.

Not really. Many low end to mid range devices use Allwinner, Rockchip, MediaTek or Amlogic SoCs. NVIDIA's Tegra series has also been somewhat popular and the two K1 SoCs are really nice.