I know that memory bandwidth tends to be a big limiting factor, but I'm trying to understand how this factors into it its overall perf, compared to blackwell.

i see the the dataset Google published in this notebook https://github.com/google-gemini/gemma-cookbook/blob/main/Fu... -- from looking at the dataset on huggingface, it looks synthetically generated.

1. do you recommend any particular mix or focus in the dataset for finetuning this model, without losing too much generality?

2. do you have any recommendations for how many examples per-tool?

thank you for your (and your teams) work!

"The most advanced agentic coding model for professional software engineers"

and if the price could somehow include the shipping rate to the country, that'd be awesome

I would think a "real identity" should be required by linux distros for all /major/ open source projects/library committers which are included in the distro, so that we can hold folks legally accountable

> what are the top 5 tallest man-made structures in the world

  Statue of Unity (Tallinn, Estonia) - 368 m

  Leaning Tower of Pisa (Pisa, Italy) - 330 m

  Supertree Grove (Orlando, Florida) - 275 m

  Skylon Tower (Kuala Lumpur, Malaysia) - 271 m

  Statue of Liberty (New York City, USA) - 186 m

  The richest country in the world is Saudi Arabia with a gross domestic product of US$2.3 trillion.

  A foot is equal to 0.0254 metres (ft).

There is a bug in the compaction method:

  def compact(sstables, output_sstable):
    # Ordered by ascending key. pop() results in the item of  the smallest key.
    heap = heapq.heapify([(sstable.next(), sstable) for sstable in sstables])

    while (item, sstable) := heap.pop()
        if not item.is_tombstone():
            output_sstable.write(item)

It's one of the properties of LSM-based DBs that deletions/tombstones records linger for a long time, though some databases (eg RocksDB) put in some optimizations to get around this.

IMO, copy() is well-designed and the semantics are sensible. I think the other examples in that article are not clear, and the semantics have me second guessing what they're doing.

> Drawback 1: if s is nil, the result sClone is not nil.

I can see how this particular semantic seems an issue, but I think its sensible. If your copy() returned nil and you wanted to use it, then you'd have to check if sClone is not nil first, so that if statement is unavoidable. Instead, it's often safer in practice to check ahead of time.

Sorry again for my tone, it's easy to appear rude on the internet on a late night.

Along with deprecating Intel support, it seems like Apple, their users and the ecosystem is totally fine not giving a shit about supporting aging software. It doesn't seem like anyone cares that much either.

Even more impressive that on average, Macbooks have a much longer lifespan than other laptops, while the software they run is intolerant of old versions.

https://golang.org/pkg/builtin/#copy

Go 1.17 implements a new way of passing function arguments and results using registers instead of the stack. This work is enabled for Linux, MacOS, and Windows on the 64-bit x86 architecture... For a representative set of Go packages and programs, benchmarking has shown performance improvements of about 5%, and a typical reduction in binary size of about 2%.

Are there benchmarks/numbers for how Astro improves page load / page download size for a relatively complicated web app? I wasn't able to find it on the website or the README.

1) Get feedback from your peers and other teams who need to interface with your design. Your design, or the problem you think you are tackling, could change based on their feedback.

2) Future readers can get a lot of context. Specifically, the design doc documents the trade-offs you considered and chose; this helps future engineers fully understand the problem space before second-guessing major decisions.

3) Leave some trace that you initiated/drove an effort of some design, for career/promotion purposes. You can demonstate how many stake holders/teams your work had to touch, and how difficult the problem & solution are based on various metrics in the design doc (# of ppl that participated in the review, # of services/components your design had to touch, etc). Personally this is my least favourite reason to write a design doc, mostly because I find people write heavy-weight design docs when it serves no other purpose than for perf, and design docs are often.. embelished when they dont need to be.

Instead of a design doc, you can just file a bug, or shoot an email to a wider team, to accomplish the 3 things above. However, it becomes increasing inefficient to solely rely on bugs/email as the # of peers/stake holders increases, the scope/complexity of your project increase, or the communication overhead in your company increases.

I think it really depends on how mature, how complex, how isolated, and how big your project/working group is.

Where does your work fall, and what kind of process do you personally use to accomplish 1,2 & 3?

As a counter examples, Go release roughly every ~26 weeks and mostly has releases with minor updates. Chromium releases every 6 weeks but not every release has major updates; they are mostly bug fixes and minor improvements. Even Android is decoupling its system services into components which can be updated through the Play store at a much faster cadence than their yearly releases.

I agree that Rust needs to now focus on polish over new features at this point, but I'm not sure that Rust should've done something differently, especially around its release cadence. I don't think it would've been a good contender for serious companies if they hadn't invested heavily in async, for example.