From a9f1ed883ead6fe3c9d52c93d9de2059e96a1524 Mon Sep 17 00:00:00 2001 From: EuAndreh Date: Mon, 24 Feb 2020 02:26:34 -0300 Subject: Move draft posts to _drafts --- ...2020-02-11-on-webassembly-killing-javascript.md | 205 +++++++++++++++++++++ .../2020-02-20-book-review-database-internals.md | 24 +++ _drafts/2020-03-30-data-formats-a-comparison.md | 10 + ...2020-02-11-on-webassembly-killing-javascript.md | 205 --------------------- .../2020-02-20-book-review-database-internals.md | 24 --- _posts/2020-03-30-data-formats-a-comparison.md | 10 - 6 files changed, 239 insertions(+), 239 deletions(-) create mode 100644 _drafts/2020-02-11-on-webassembly-killing-javascript.md create mode 100644 _drafts/2020-02-20-book-review-database-internals.md create mode 100644 _drafts/2020-03-30-data-formats-a-comparison.md delete mode 100644 _posts/2020-02-11-on-webassembly-killing-javascript.md delete mode 100644 _posts/2020-02-20-book-review-database-internals.md delete mode 100644 _posts/2020-03-30-data-formats-a-comparison.md diff --git a/_drafts/2020-02-11-on-webassembly-killing-javascript.md b/_drafts/2020-02-11-on-webassembly-killing-javascript.md new file mode 100644 index 0000000..998c176 --- /dev/null +++ b/_drafts/2020-02-11-on-webassembly-killing-javascript.md @@ -0,0 +1,205 @@ +--- +title: On WebAssembly killing JavaScript +date: 2020-02-11 +layout: post +lang: en +ref: on-webassembly-killing-javascript +--- +When discussing WebAssembly (WASM), I often see people portraiting it too much +as a JavaScript replacement, but I think this framing misses the point of some +of the aspects on how WASM can be a great tool: being a portability oportunity, +which means increasing the reach to code. + +If you think of WASM strictly as a optimization of JavaScript, that's where +you'll end up: WASM is the same as JavaScript, but faster. + +But there's a more interesting aspect (to me) of it: portability. That means you +can now write multiplatforme code that runs everywhere. I mean, everywhere, even +in the browser. Let's imagine how you could write SQLite and mke it run on the Web. + +# SQLite + +If I were to create, say, SQLite today, I would consider adding web support for +it. SQLite already is available almost everywhere[^1]. This is due to it having +very so few dependencies, + +Imagine having writing SQLite today + +There are also other legimate uses of WASM, such as WASI and etc. + +Here's how I would start writing an application that could run on any POSIX +system and, on top of that, could run on the browser: + +``` +// api.h + +extern void platformDependentPersistInt(int); +extern int platformDependentRetrieveInt(); + + +// api-posix.c + +/* POSIX implementation of "api.h" interface to be used in non-web contexts */ + +#include + +void platformDependentPersistInt(int n) { + FILE* fp = fopen("/tmp/persisted.txt", "w+"); + fprintf(fp, "%d", n); + fclose(fp); +} + +int platformDependentRetrieveInt() { + FILE* fp = fopen("/tmp/persisted.txt", "r"); + int persisted = fgetc(fp); + return persisted; +} + + +// api-wasm.js + +/* WASM implementation of "api.h" interface to be used in web contexts */ + +export const platformDependentPersistInt = (n) => + localStorage.setItem("persisted", n.toString()); + +export const platformDependentRetrieveInt = () => + parseInt(localStorage.getItem("persisted")); + + +// add.h + +int add(int a, int b); +void persistInt(int n); +int retrieveInt(); + + +// add.c + +#include "api.h" + +int add(int a, int b) { + return a * a + b; +} + +void persistInt(int n) { + platformDependentPersistInt(n); +} + +int retrieveInt() { + return platformDependentRetrieveInt(); +} +``` + +``` +// main.c + +#include +#include "add.h" + +int main() { + int added = add(4, 5); + printf("Adding 4 and 5: %d\n", added); + + persistInt(6); + int persisted = retrieveInt(); + printf("Persisted number: %c\n", persisted); + return 0; +} + + +// index.html + + +``` + +In order to +``` +// server.py + +#!/usr/bin/env python +import SimpleHTTPServer +import SocketServer + +PORT = 8001 + +class Handler(SimpleHTTPServer.SimpleHTTPRequestHandler): + pass + +Handler.extensions_map['.wasm'] = 'application/wasm' + +httpd = SocketServer.TCPServer(("", PORT), Handler) + +print "serving at port", PORT +httpd.serve_forever() +``` + +Dependency graph: +api-posix.c api-wasm.js +api.h +add.h +add.c +main.c index.html + +Compiling and running the POSIX code: +```shell +$ clang -o add main.c add.c api-posix.c +$ ./add +Adding 4 and 5: 21 +Persisted number: 6 +``` + +Compiling and running the WASM +```shell +$ clang \ + --target=wasm32 \ + -nostdlib \ + -Wl,--no-entry \ + -Wl,--export-all \ + -Wl,--allow-undefined \ + -o add.wasm \ + add.c +$ ./server.py +``` + +After opening the browser, the console shows: +``` +Adding 4 and 5: 21 +Persisted number: 6 +``` + +Rust, C, Zig + +No Emscripten, no GC, no runtime + +Emscripten 11KB + +# Limitations + +"System call" cost in WebAssembly. + +WASM is very new, no flush guarantees. + +Confusing dependency tree + +AFAICT you can't package WASM with JavaScript. + + +[^1]: [Platforms supported by SQLite are](https://sqlite.org/features.html): + "Android, *BSD, iOS, Linux, Mac, Solaris, VxWorks, and Windows (Win32, + WinCE, WinRT) are supported out of the box. Easy to port to other systems". + +https://sqlite.org/selfcontained.html diff --git a/_drafts/2020-02-20-book-review-database-internals.md b/_drafts/2020-02-20-book-review-database-internals.md new file mode 100644 index 0000000..8cac601 --- /dev/null +++ b/_drafts/2020-02-20-book-review-database-internals.md @@ -0,0 +1,24 @@ +--- +title: Book review - "Database Internals" +date: 2020-02-20 +layout: post +lang: en +ref: book-review-database-internals +--- +I'm now reading the "Database Internals" book, by Alex Petrov. I'm liking it a +lot, and I have a similar feeling at the end of each chapter of when I was +reading "Designing Data-Intensive Applications": each chapter has some +references to other books, articles and resources, and I feel like I should go +and reach all of them to have a deeper understanding of the subject. + +It gives just enough historical background in the text itself to show that the +author does have knowledge in this area. + +# Chapter 1: Introduction and Overview + +The covering of basic vocabulary (column vs wide-column) is very good and +straightforward, and the fundamental trade-offs are shown very clearly, like +in-memory and disk-based storage, primary-keys and offset lookups, etc. + +Finishing this chapter I was happy with it's content and looking forward for a +more in-depth tour of many of the concepts presented here. diff --git a/_drafts/2020-03-30-data-formats-a-comparison.md b/_drafts/2020-03-30-data-formats-a-comparison.md new file mode 100644 index 0000000..9df7db5 --- /dev/null +++ b/_drafts/2020-03-30-data-formats-a-comparison.md @@ -0,0 +1,10 @@ +--- +title: Data formats - a comparison +date: 2020-03-30 +layout: post +lang: en +ref: data-formats-a-comparison +--- +Avro, EDN, etc. (The Language of the system) + +Look at column store data formats too? Parquet, ORC, etc. (Database Internals book) diff --git a/_posts/2020-02-11-on-webassembly-killing-javascript.md b/_posts/2020-02-11-on-webassembly-killing-javascript.md deleted file mode 100644 index 998c176..0000000 --- a/_posts/2020-02-11-on-webassembly-killing-javascript.md +++ /dev/null @@ -1,205 +0,0 @@ ---- -title: On WebAssembly killing JavaScript -date: 2020-02-11 -layout: post -lang: en -ref: on-webassembly-killing-javascript ---- -When discussing WebAssembly (WASM), I often see people portraiting it too much -as a JavaScript replacement, but I think this framing misses the point of some -of the aspects on how WASM can be a great tool: being a portability oportunity, -which means increasing the reach to code. - -If you think of WASM strictly as a optimization of JavaScript, that's where -you'll end up: WASM is the same as JavaScript, but faster. - -But there's a more interesting aspect (to me) of it: portability. That means you -can now write multiplatforme code that runs everywhere. I mean, everywhere, even -in the browser. Let's imagine how you could write SQLite and mke it run on the Web. - -# SQLite - -If I were to create, say, SQLite today, I would consider adding web support for -it. SQLite already is available almost everywhere[^1]. This is due to it having -very so few dependencies, - -Imagine having writing SQLite today - -There are also other legimate uses of WASM, such as WASI and etc. - -Here's how I would start writing an application that could run on any POSIX -system and, on top of that, could run on the browser: - -``` -// api.h - -extern void platformDependentPersistInt(int); -extern int platformDependentRetrieveInt(); - - -// api-posix.c - -/* POSIX implementation of "api.h" interface to be used in non-web contexts */ - -#include - -void platformDependentPersistInt(int n) { - FILE* fp = fopen("/tmp/persisted.txt", "w+"); - fprintf(fp, "%d", n); - fclose(fp); -} - -int platformDependentRetrieveInt() { - FILE* fp = fopen("/tmp/persisted.txt", "r"); - int persisted = fgetc(fp); - return persisted; -} - - -// api-wasm.js - -/* WASM implementation of "api.h" interface to be used in web contexts */ - -export const platformDependentPersistInt = (n) => - localStorage.setItem("persisted", n.toString()); - -export const platformDependentRetrieveInt = () => - parseInt(localStorage.getItem("persisted")); - - -// add.h - -int add(int a, int b); -void persistInt(int n); -int retrieveInt(); - - -// add.c - -#include "api.h" - -int add(int a, int b) { - return a * a + b; -} - -void persistInt(int n) { - platformDependentPersistInt(n); -} - -int retrieveInt() { - return platformDependentRetrieveInt(); -} -``` - -``` -// main.c - -#include -#include "add.h" - -int main() { - int added = add(4, 5); - printf("Adding 4 and 5: %d\n", added); - - persistInt(6); - int persisted = retrieveInt(); - printf("Persisted number: %c\n", persisted); - return 0; -} - - -// index.html - - -``` - -In order to -``` -// server.py - -#!/usr/bin/env python -import SimpleHTTPServer -import SocketServer - -PORT = 8001 - -class Handler(SimpleHTTPServer.SimpleHTTPRequestHandler): - pass - -Handler.extensions_map['.wasm'] = 'application/wasm' - -httpd = SocketServer.TCPServer(("", PORT), Handler) - -print "serving at port", PORT -httpd.serve_forever() -``` - -Dependency graph: -api-posix.c api-wasm.js -api.h -add.h -add.c -main.c index.html - -Compiling and running the POSIX code: -```shell -$ clang -o add main.c add.c api-posix.c -$ ./add -Adding 4 and 5: 21 -Persisted number: 6 -``` - -Compiling and running the WASM -```shell -$ clang \ - --target=wasm32 \ - -nostdlib \ - -Wl,--no-entry \ - -Wl,--export-all \ - -Wl,--allow-undefined \ - -o add.wasm \ - add.c -$ ./server.py -``` - -After opening the browser, the console shows: -``` -Adding 4 and 5: 21 -Persisted number: 6 -``` - -Rust, C, Zig - -No Emscripten, no GC, no runtime - -Emscripten 11KB - -# Limitations - -"System call" cost in WebAssembly. - -WASM is very new, no flush guarantees. - -Confusing dependency tree - -AFAICT you can't package WASM with JavaScript. - - -[^1]: [Platforms supported by SQLite are](https://sqlite.org/features.html): - "Android, *BSD, iOS, Linux, Mac, Solaris, VxWorks, and Windows (Win32, - WinCE, WinRT) are supported out of the box. Easy to port to other systems". - -https://sqlite.org/selfcontained.html diff --git a/_posts/2020-02-20-book-review-database-internals.md b/_posts/2020-02-20-book-review-database-internals.md deleted file mode 100644 index 713c57b..0000000 --- a/_posts/2020-02-20-book-review-database-internals.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Book review: "Database Internals" -date: 2020-02-20 -layout: post -lang: en -ref: book-review-database-internals ---- -I'm now reading the "Database Internals" book, by Alex Petrov. I'm liking it a -lot, and I have a similar feeling at the end of each chapter of when I was -reading "Designing Data-Intensive Applications": each chapter has some -references to other books, articles and resources, and I feel like I should go -and reach all of them to have a deeper understanding of the subject. - -It gives just enough historical background in the text itself to show that the -author does have knowledge in this area. - -# Chapter 1: Introduction and Overview - -The covering of basic vocabulary (column vs wide-column) is very good and -straightforward, and the fundamental trade-offs are shown very clearly, like -in-memory and disk-based storage, primary-keys and offset lookups, etc. - -Finishing this chapter I was happy with it's content and looking forward for a -more in-depth tour of many of the concepts presented here. diff --git a/_posts/2020-03-30-data-formats-a-comparison.md b/_posts/2020-03-30-data-formats-a-comparison.md deleted file mode 100644 index d69fee2..0000000 --- a/_posts/2020-03-30-data-formats-a-comparison.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Data formats: a comparison -date: 2020-03-30 -layout: post -lang: en -ref: data-formats-a-comparison ---- -Avro, EDN, etc. (The Language of the system) - -Look at column store data formats too? Parquet, ORC, etc. (Database Internals book) -- cgit v1.2.3