5 ms·

Hi! I saw your PR review of a community effort to add Bun to the Techempower benchmark. You had really great, exact feedback about "unnecessary allocation here"

Hi! I saw your PR review of a community effort to add Bun to the Techempower benchmark. You had really great, exact feedback about "unnecessary allocation here", "unnecessary allocation there". It was eye-opening, in terms of how often us JS programmers play fast & loose with "a little filter" here, "a little map" there, and end up with death by a thousand allocations. Given that context, I'm curious: 1) How much you think Bun's (super-appreciated!) fanatical OCD about optimizing everything "up to & outside of JSC" will translate to the post-boot performance of everyday backend apps, and 2) If you're tempted/could be compelled :-D to create a "Mojo of TypeScript", where you do a collab with Anders Hejlsberg to create some sort of "TypeScript-ish" language that, if a TS programmer plays by a stricter set of rules + relies on the latest borrowing inference magic, we could bring some of the Bun amazing-performance ethos to the current idiomatic FP/JS/TS style that is "lol allocations everywhere". :-) Or, maybe with Bun bringing the right native/HTTP/etc libraries wrapped around the core runtime, doing "just the business logic" in JS really won't be that bad? Which iirc was the theory/assertion of just-js when its author was benchmark hacking Techempower, and got pretty far with that approach. Anyway, thanks for Bun! We're not running on it yet, but it's on the todo list. :-)

re-thc 3y ago
> PR review of a community effort to add Bun to the Techempower benchmark Has this been added? That PR got closed right? Whilst valid, it was sad that Bun didn't make it. Would be good if someone from the community or Bun team can give it another go.
genuine_smiles 3y ago
Does anyone have a link to the PR?
polyrand 3y ago
PR link: https://github.com/TechEmpower/FrameworkBenchmarks/pull/8337 https://github.com/TechEmpower/FrameworkBenchmarks/pull/8337
dapperdrake 3y ago
Concerning stephen's item (2). The stricter set of rules was laid out by Richard C. Waters in Optimization of Series Expressions: Part I: User's Manual for the Series Macro Package, page 46 (document page 48). See reference Waters(1989a). The paper's language is a bit different than contemporary (2023) language. `map()` is called `map-fn`. `reduce()` a.k.a. `fold` seems to be `collect-fn`, although `collecting-fn` also seems interesting. sorting, uniqueness and permutation seem to be covered by `producing`. Just think of McIlroy's famous pipeline in response to Donald Knuth's trie implementation[mcilroy-source]: tr -cs A-Za-z '\n' | tr A-Z a-z | sort | uniq -c | sort -rn | sed ${1}q As far as pipeline or stream processing diagrams are concerned, the diagram on page 13 (document page 15) of Waters(1989a) may also be worth a closer look. What the SERIES compiler does is pipeline the loops. Think of a UNIX shell pipeline. Think of streaming results. Waters calls this pre-order processing. This also seems to be where Rich Hickey got the term "transducer" from. In short it means dropping unnecessary intermediate list or array allocations. Shameless self-plug: Eliminated unnecessary allocations in my JavaScript code by adding support for SERIES to the PARENSCRIPT Common Lisp to JavaScript compiler. The trick was (1) to define (series-expand ...) on series expressions so that they can be passed into (parenscript:ps ...) and (2) the parenscript compiler was missing (tagbody ... (go ...) ...) support. The latter is surprisingly tricky to implement. See dapperdrake(2023). Apologies for the less than perfect blog post. Got busy actually using this tool. Suddenly stream processing is easy, and maintainable. When adding a Hylang-style threading macro (-> ...) you get UNIX style pipelines without unnecessary allocations. It looks similar to this: (-> (it :let*-symbol series::let) (scan-file in-path-name #'read) (map-fn T #'some-function it) (collect 'list it)) Sadly, the SERIES compiler available on quicklisp right now is a bit arcane to use. It seems like it may have been more user friendly if it would have been integrated into the ANSI Common Lisp 1995 standard so that is has access to compiler internals. The trick seems to be to use macros instead of (series::defun ...) and use (series::let ...) instead of (cl:let ...). Note, that the two crucial symbols 'defun and 'let are not exported by SERIES. So using the package is insufficient and pipelining fails without a decent warning. Am chewing on the SERIES source code. It is available on sourceforge. [series-source]. If anybody is interested in porting it, then please reach out. It seems to be of similar importance as Google's V8 relooper algorithm [relooper-reference]. Waters(1989b), page 27 (document page 29) even demonstrates an implementation for Pascal. So it is possible. References: dapperdrake(2023): Faster Loops in JavaScript https://dapperdrake.neocities.org/faster-loops-javascript https://dapperdrake.neocities.org/faster-loops-javascript Waters(1989a) document page 48, paper page 46 https://dspace.mit.edu/bitstream/handle/1721.1/6035/AIM-1082.pdf?sequence=2&isAllowed=y#page=48 https://dspace.mit.edu/bitstream/handle/1721.1/6035/AIM-1082... Waters(1989b) document page 29, paper page 27 https://dspace.mit.edu/bitstream/handle/1721.1/6031/AIM-1083.pdf?sequence=2&isAllowed=y#page=29 https://dspace.mit.edu/bitstream/handle/1721.1/6031/AIM-1083... [relooper-reference] http://troubles.md/why-do-we-need-the-relooper-algorithm-again/ http://troubles.md/why-do-we-need-the-relooper-algorithm-aga... [series-source] https://series.sourceforge.net/ https://series.sourceforge.net/ [mcilroy-source] https://franklinchen.com/blog/2011/12/08/revisiting-knuth-and-mcilroys-word-count-programs/ https://franklinchen.com/blog/2011/12/08/revisiting-knuth-an...
vorticalbox 3y ago
> us JS programmers play fast & loose with "a little filter" here, "a little map" there, and end up with death by a thousand allocations. That's because speed isn't always top priority. Readability is very high on the list. I would rather have a slightly slower .map or .filter in a chain than a harder to read nested for or while loop.
- geodel 3y ago
  Yeah, besides Javascript runs to client side so let client deal with bad perf. I am happy writing my beautifully designed readable code.
  - ranguna 3y ago
    Javascript also runs on server side.
- dralley 3y ago
  A nested for or while loop isn't always less readable FWIW. If you need more than 3-4 filters and/or maps the balance starts shifting back the other way.
- hinkley 3y ago
  Well-factored code often reveals more important optimizations one can make. Like figuring out the nested loop isn't really necessary.
- flohofwoe 3y ago
  This just shows again that readability is entirely subjective, IMHO combinations of .map, .filter, .reduce, etc are often less readable than doing the same thing in a nested loop.
  - vorticalbox 3y ago
    This is true I code very functional style in javascript but I can see how that might be harder to read for some.
  - 3y ago
Jarred 3y ago
> 1) How much you think Bun's (super-appreciated!) fanatical OCD about optimizing everything "up to & outside of JSC" will translate to the post-boot performance of everyday backend apps Bun is extremely fast at data processing tasks. Shuffling data from one place to another (disk, network, APIs, etc). We use SIMD, minimize allocations/copies and pay lots of attention to what system calls are used and how often and where. A naively implemented script in Bun that moves data using Bun’s APIs will often outperform a naively implemented program written in Rust or Go. Bun’s APIs try really hard to make the obvious & default way also the fast way. That, and Bun’s builtin build tooling are where Bun’s performance shines. > “Mojo of TypeScript” I’ve thought a little about this. I think it’s a project that’d take 5+ years and crazy hard to hire the right people to do it. I think it’s mostly unnecessary though. JITs are really good. The API design is usually the reason why things aren’t as fast as they could be.
- the_duke 3y ago
  > A naively implemented script in Bun that moves data using Bun’s APIs will often outperform a naively implemented program written in Rust or Go. Sounds exciting, do you have some example benchmarks I can run that show this?
- vaughan 3y ago
  > I think it’s a project that’d take 5+ years What are the major difficulties you see? Is this estimate for supporting all existing TS code...or as the OC said, a new language with only newly written code. The way I naively think about it is to imagine transpiling TypeScript code to Zig code. How far could that take you? And if you restricted how much dynamic-y stuff you could do...maybe with a linter. I always get the feeling that 90% of the business logic (sequence, selection, iteration) is that same between languages whether they are interpreted or compiled, with just some memory management stuff added on top - which can be abstracted anyway.
- stephen 3y ago
  > Bun’s APIs try really hard to make the obvious & default way > also the fast way. Nice! That makes a lot of sense, and look forward to trying them. Fwiw I sometimes worry about the slippery slope to infra that exists on the JS side, i.e. I work a lot in a GraphQL backend, and even if Bun gave us (or really our framework, so fastify/mercurius) a super-optimized way of getting the raw bytes off the wire, Mercurius is still doing GraphQL parsing, validation, routing, response building in JS land. Granted, I want to keep my application's business logic in TS, but naively it seems tempting to push as much of the "web framework" / "graphql framework" as possible into the native side of things, where as I think historically Node/etc API have stopped at the "here's the raw HTTP request off the wire". > I’ve thought a little about this. Sweet! That's awesome just to hear that it's crossed your mind. Agreed it would be a moonshot. And, yeah, I'm perfectly happy leaning into JITs and good APIs. Thanks for the reply!
madeofpalk 3y ago
> some sort of "TypeScript-ish" language that, if a TS programmer plays by a stricter set of rules This is basically just rust, no? As a TS developer, I've found picking up rust to be really neat.
- CharlieDigital 3y ago
  Try C# instead.
  - madeofpalk 3y ago
    I write a fair bit of C#. It feels like the prequal to Typescript. Its lack of discriminated unions and type narrowing feels like a step back from Typescript.
    - no_wizard 3y ago
      Given that TypeScript is driven in late part by one of the main long term (until they moved to TS) C# language designers, I feel a lot of the core of the TS type system is what they wanted to do in C# but for legacy reasons just can’t.
    - CharlieDigital 3y ago
      DU is available in C# via packages like OneOf and Dunet. Dunet is really good. https://github.com/mcintyre321/OneOf https://github.com/mcintyre321/OneOf https://github.com/domn1995/dunet https://github.com/domn1995/dunet It's on the roadmap and will arrive at some point: https://github.com/dotnet/csharplang/blob/main/proposals/discriminated-unions.md https://github.com/dotnet/csharplang/blob/main/proposals/dis...
- stephen 3y ago
  No. :-) That was certainly the promise/hype of Rust ~2-3 years ago, that it was going to become so ergonomic that even "boring line-of-business applications" (i.e. JS backends) could be written in Rust, by everyday programmers, without any slow down in delivery/velocity due to the language complexity. But, from what I've seen, that's not played out, and instead the community is still on the look out for the killer "systems-language performance, but scripting-language ergonomics" language.
deleted 3y ago
[deleted]

re-thc 3y ago

> PR review of a community effort to add Bun to the Techempower benchmark Has this been added? That PR got closed right? Whilst valid, it was sad that Bun didn't make it. Would be good if someone from the community or Bun team can give it another go.

genuine_smiles 3y ago

Does anyone have a link to the PR?

polyrand 3y ago

PR link: https://github.com/TechEmpower/FrameworkBenchmarks/pull/8337 https://github.com/TechEmpower/FrameworkBenchmarks/pull/8337

dapperdrake 3y ago

Concerning stephen's item (2). The stricter set of rules was laid out by Richard C. Waters in Optimization of Series Expressions: Part I: User's Manual for the Series Macro Package, page 46 (document page 48). See reference Waters(1989a). The paper's language is a bit different than contemporary (2023) language. `map()` is called `map-fn`. `reduce()` a.k.a. `fold` seems to be `collect-fn`, although `collecting-fn` also seems interesting. sorting, uniqueness and permutation seem to be covered by `producing`. Just think of McIlroy's famous pipeline in response to Donald Knuth's trie implementation[mcilroy-source]: tr -cs A-Za-z '\n' | tr A-Z a-z | sort | uniq -c | sort -rn | sed ${1}q As far as pipeline or stream processing diagrams are concerned, the diagram on page 13 (document page 15) of Waters(1989a) may also be worth a closer look. What the SERIES compiler does is pipeline the loops. Think of a UNIX shell pipeline. Think of streaming results. Waters calls this pre-order processing. This also seems to be where Rich Hickey got the term "transducer" from. In short it means dropping unnecessary intermediate list or array allocations. Shameless self-plug: Eliminated unnecessary allocations in my JavaScript code by adding support for SERIES to the PARENSCRIPT Common Lisp to JavaScript compiler. The trick was (1) to define (series-expand ...) on series expressions so that they can be passed into (parenscript:ps ...) and (2) the parenscript compiler was missing (tagbody ... (go ...) ...) support. The latter is surprisingly tricky to implement. See dapperdrake(2023). Apologies for the less than perfect blog post. Got busy actually using this tool. Suddenly stream processing is easy, and maintainable. When adding a Hylang-style threading macro (-> ...) you get UNIX style pipelines without unnecessary allocations. It looks similar to this: (-> (it :let*-symbol series::let) (scan-file in-path-name #'read) (map-fn T #'some-function it) (collect 'list it)) Sadly, the SERIES compiler available on quicklisp right now is a bit arcane to use. It seems like it may have been more user friendly if it would have been integrated into the ANSI Common Lisp 1995 standard so that is has access to compiler internals. The trick seems to be to use macros instead of (series::defun ...) and use (series::let ...) instead of (cl:let ...). Note, that the two crucial symbols 'defun and 'let are not exported by SERIES. So using the package is insufficient and pipelining fails without a decent warning. Am chewing on the SERIES source code. It is available on sourceforge. [series-source]. If anybody is interested in porting it, then please reach out. It seems to be of similar importance as Google's V8 relooper algorithm [relooper-reference]. Waters(1989b), page 27 (document page 29) even demonstrates an implementation for Pascal. So it is possible. References: dapperdrake(2023): Faster Loops in JavaScript https://dapperdrake.neocities.org/faster-loops-javascript https://dapperdrake.neocities.org/faster-loops-javascript Waters(1989a) document page 48, paper page 46 https://dspace.mit.edu/bitstream/handle/1721.1/6035/AIM-1082.pdf?sequence=2&isAllowed=y#page=48 https://dspace.mit.edu/bitstream/handle/1721.1/6035/AIM-1082... Waters(1989b) document page 29, paper page 27 https://dspace.mit.edu/bitstream/handle/1721.1/6031/AIM-1083.pdf?sequence=2&isAllowed=y#page=29 https://dspace.mit.edu/bitstream/handle/1721.1/6031/AIM-1083... [relooper-reference] http://troubles.md/why-do-we-need-the-relooper-algorithm-again/ http://troubles.md/why-do-we-need-the-relooper-algorithm-aga... [series-source] https://series.sourceforge.net/ https://series.sourceforge.net/ [mcilroy-source] https://franklinchen.com/blog/2011/12/08/revisiting-knuth-and-mcilroys-word-count-programs/ https://franklinchen.com/blog/2011/12/08/revisiting-knuth-an...

vorticalbox 3y ago

> us JS programmers play fast & loose with "a little filter" here, "a little map" there, and end up with death by a thousand allocations. That's because speed isn't always top priority. Readability is very high on the list. I would rather have a slightly slower .map or .filter in a chain than a harder to read nested for or while loop.

geodel 3y ago
Yeah, besides Javascript runs to client side so let client deal with bad perf. I am happy writing my beautifully designed readable code.
- ranguna 3y ago
  Javascript also runs on server side.
dralley 3y ago
A nested for or while loop isn't always less readable FWIW. If you need more than 3-4 filters and/or maps the balance starts shifting back the other way.
hinkley 3y ago
Well-factored code often reveals more important optimizations one can make. Like figuring out the nested loop isn't really necessary.
flohofwoe 3y ago
This just shows again that readability is entirely subjective, IMHO combinations of .map, .filter, .reduce, etc are often less readable than doing the same thing in a nested loop.
- vorticalbox 3y ago
  This is true I code very functional style in javascript but I can see how that might be harder to read for some.
- 3y ago

Jarred 3y ago

> 1) How much you think Bun's (super-appreciated!) fanatical OCD about optimizing everything "up to & outside of JSC" will translate to the post-boot performance of everyday backend apps Bun is extremely fast at data processing tasks. Shuffling data from one place to another (disk, network, APIs, etc). We use SIMD, minimize allocations/copies and pay lots of attention to what system calls are used and how often and where. A naively implemented script in Bun that moves data using Bun’s APIs will often outperform a naively implemented program written in Rust or Go. Bun’s APIs try really hard to make the obvious & default way also the fast way. That, and Bun’s builtin build tooling are where Bun’s performance shines. > “Mojo of TypeScript” I’ve thought a little about this. I think it’s a project that’d take 5+ years and crazy hard to hire the right people to do it. I think it’s mostly unnecessary though. JITs are really good. The API design is usually the reason why things aren’t as fast as they could be.

the_duke 3y ago
> A naively implemented script in Bun that moves data using Bun’s APIs will often outperform a naively implemented program written in Rust or Go. Sounds exciting, do you have some example benchmarks I can run that show this?
vaughan 3y ago
> I think it’s a project that’d take 5+ years What are the major difficulties you see? Is this estimate for supporting all existing TS code...or as the OC said, a new language with only newly written code. The way I naively think about it is to imagine transpiling TypeScript code to Zig code. How far could that take you? And if you restricted how much dynamic-y stuff you could do...maybe with a linter. I always get the feeling that 90% of the business logic (sequence, selection, iteration) is that same between languages whether they are interpreted or compiled, with just some memory management stuff added on top - which can be abstracted anyway.
stephen 3y ago
> Bun’s APIs try really hard to make the obvious & default way > also the fast way. Nice! That makes a lot of sense, and look forward to trying them. Fwiw I sometimes worry about the slippery slope to infra that exists on the JS side, i.e. I work a lot in a GraphQL backend, and even if Bun gave us (or really our framework, so fastify/mercurius) a super-optimized way of getting the raw bytes off the wire, Mercurius is still doing GraphQL parsing, validation, routing, response building in JS land. Granted, I want to keep my application's business logic in TS, but naively it seems tempting to push as much of the "web framework" / "graphql framework" as possible into the native side of things, where as I think historically Node/etc API have stopped at the "here's the raw HTTP request off the wire". > I’ve thought a little about this. Sweet! That's awesome just to hear that it's crossed your mind. Agreed it would be a moonshot. And, yeah, I'm perfectly happy leaning into JITs and good APIs. Thanks for the reply!

madeofpalk 3y ago

> some sort of "TypeScript-ish" language that, if a TS programmer plays by a stricter set of rules This is basically just rust, no? As a TS developer, I've found picking up rust to be really neat.

CharlieDigital 3y ago
Try C# instead.
- madeofpalk 3y ago
  I write a fair bit of C#. It feels like the prequal to Typescript. Its lack of discriminated unions and type narrowing feels like a step back from Typescript.
  - no_wizard 3y ago
    Given that TypeScript is driven in late part by one of the main long term (until they moved to TS) C# language designers, I feel a lot of the core of the TS type system is what they wanted to do in C# but for legacy reasons just can’t.
  - CharlieDigital 3y ago
    DU is available in C# via packages like OneOf and Dunet. Dunet is really good. https://github.com/mcintyre321/OneOf https://github.com/mcintyre321/OneOf https://github.com/domn1995/dunet https://github.com/domn1995/dunet It's on the roadmap and will arrive at some point: https://github.com/dotnet/csharplang/blob/main/proposals/discriminated-unions.md https://github.com/dotnet/csharplang/blob/main/proposals/dis...
stephen 3y ago
No. :-) That was certainly the promise/hype of Rust ~2-3 years ago, that it was going to become so ergonomic that even "boring line-of-business applications" (i.e. JS backends) could be written in Rust, by everyday programmers, without any slow down in delivery/velocity due to the language complexity. But, from what I've seen, that's not played out, and instead the community is still on the look out for the killer "systems-language performance, but scripting-language ergonomics" language.

deleted 3y ago

[deleted]