From 98ad4d0a250949f4a8b180060e9d73f15016c2c1 Mon Sep 17 00:00:00 2001 From: ferhat elmas Date: Fri, 10 Nov 2017 21:31:51 +0100 Subject: [PATCH] haskell-as-c: typo fixes --- write_haskell_as_fast_as_c.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/write_haskell_as_fast_as_c.md b/write_haskell_as_fast_as_c.md index 22d08e4..4fb86d2 100644 --- a/write_haskell_as_fast_as_c.md +++ b/write_haskell_as_fast_as_c.md @@ -160,7 +160,7 @@ We can also confirm that the input list is allocated lazily. in .. ``` -The 'let' here is the lazy allocation primitive. If you see it on non-unboxed type, you can be sure that thing will be lazily allocated on the heap. Remeber: core is like Haskell, but there's only 'let' and 'case' (one for laziness, one for evaluation). +The 'let' here is the lazy allocation primitive. If you see it on non-unboxed type, you can be sure that thing will be lazily allocated on the heap. Remember: core is like Haskell, but there's only 'let' and 'case' (one for laziness, one for evaluation). So that's good. It means the list itself isn't costing us anything to write. This lazy allocation also explains why we're able to make some progress before running out of memory resources -- the list is only allocated as we traverse it. @@ -399,7 +399,7 @@ Note the very tight inner loop, and final division. Meanwhile, GHC produces, wit divsd %xmm0,%xmm5 ``` -Quite a bit more junk in the inner loop, which explains the slowdown with -fasm. That native code gen needs more work for competitve floating point work. But with the GHC C backend: +Quite a bit more junk in the inner loop, which explains the slowdown with -fasm. That native code gen needs more work for competitive floating point work. But with the GHC C backend: ```asm s1bn_info: