Skip to content

Commit bdd3bb8

Browse files
authored
Merge pull request #2403 from odidev/typescr_LP
Deploy TypeScript on Google Cloud C4A (Arm-based Axion VMs)
2 parents a12193d + 91836d7 commit bdd3bb8

File tree

8 files changed

+403
-0
lines changed

8 files changed

+403
-0
lines changed
Lines changed: 64 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,64 @@
1+
---
2+
title: Deploy TypeScript on Google Cloud C4A (Arm-based Axion VMs)
3+
4+
draft: true
5+
cascade:
6+
draft: true
7+
8+
minutes_to_complete: 30
9+
10+
who_is_this_for: This learning path is intended for software developers deploying and optimizing TypeScript workloads on Linux/Arm64 environments, specifically using Google Cloud C4A virtual machines powered by Axion processors.
11+
12+
learning_objectives:
13+
- Provision an Arm-based SUSE SLES virtual machine on Google Cloud (C4A with Axion processors)
14+
- Install TypeScript on a SUSE Arm64 (C4A) instance
15+
- Validate TypeScript functionality by creating, compiling, and running a simple TypeScript script on the Arm64 VM
16+
- Benchmark TypeScript performance using a JMH-style custom benchmark with perf_hooks on Arm64 (Aarch64) architecture
17+
18+
prerequisites:
19+
- A [Google Cloud Platform (GCP)](https://cloud.google.com/free) account with billing enabled
20+
- Basic familiarity with [TypeScript](https://www.typescriptlang.org/) and Node.js runtime environment
21+
22+
23+
author: Pareena Verma
24+
25+
##### Tags
26+
skilllevels: Introductory
27+
subjects: Web
28+
cloud_service_providers: Google Cloud
29+
30+
armips:
31+
- Neoverse
32+
33+
tools_software_languages:
34+
- TypeScript
35+
- node.js
36+
- npm
37+
- perf_hooks
38+
39+
operatingsystems:
40+
- Linux
41+
42+
# ================================================================================
43+
# FIXED, DO NOT MODIFY
44+
# ================================================================================
45+
further_reading:
46+
- resource:
47+
title: Google Cloud documentation
48+
link: https://cloud.google.com/docs
49+
type: documentation
50+
51+
- resource:
52+
title: TypeScript documentation
53+
link: https://www.typescriptlang.org/docs/
54+
type: documentation
55+
56+
- resource:
57+
title: TypeScript Benchmark documentation
58+
link: https://tech.spiko.io/posts/benchmarking-typescript-type-checking/
59+
type: documentation
60+
61+
weight: 1
62+
layout: "learningpathall"
63+
learning_path_main_page: "yes"
64+
---
Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
---
2+
# ================================================================================
3+
# FIXED, DO NOT MODIFY THIS FILE
4+
# ================================================================================
5+
weight: 21 # Set to always be larger than the content in this path to be at the end of the navigation.
6+
title: "Next Steps" # Always the same, html page title.
7+
layout: "learningpathall" # All files under learning paths have this same wrapper for Hugo processing.
8+
---
Lines changed: 23 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,23 @@
1+
---
2+
title: Getting started with TypeScript on Google Axion C4A (Arm Neoverse-V2)
3+
4+
weight: 2
5+
6+
layout: "learningpathall"
7+
---
8+
9+
## Google Axion C4A Arm instances in Google Cloud
10+
11+
Google Axion C4A is a family of Arm-based virtual machines built on Google’s custom Axion CPU, which is based on Arm Neoverse-V2 cores. Designed for high-performance and energy-efficient computing, these virtual machines offer strong performance for modern cloud workloads such as CI/CD pipelines, microservices, media processing, and general-purpose applications.
12+
13+
The C4A series provides a cost-effective alternative to x86 virtual machines while leveraging the scalability and performance benefits of the Arm architecture in Google Cloud.
14+
15+
To learn more about Google Axion, refer to the [Introducing Google Axion Processors, our new Arm-based CPUs](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu) blog.
16+
17+
## TypeScript
18+
19+
TypeScript is an open-source, strongly typed programming language developed and maintained by Microsoft.
20+
21+
It is a superset of JavaScript, which means all valid JavaScript code is also valid TypeScript, but TypeScript adds **static typing, interfaces, and advanced tooling** to help developers write more reliable and maintainable code.
22+
23+
TypeScript is widely used for **web applications, server-side development (Node.js), and large-scale JavaScript projects** where type safety and code quality are important. Learn more from the [TypeScript official website](https://www.typescriptlang.org/) and its [handbook and documentation](https://www.typescriptlang.org/docs/).
Lines changed: 99 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
---
2+
title: TypeScript Baseline Testing on Google Axion C4A Arm Virtual Machine
3+
weight: 5
4+
5+
### FIXED, DO NOT MODIFY
6+
layout: learningpathall
7+
---
8+
9+
## Baseline Setup for TypeScript
10+
This guide covers the **baseline setup and testing** of TypeScript on a **Google Axion C4A virtual machine** running SUSE Linux. The objective is to ensure that the TypeScript environment is installed correctly, that basic compilation works, and that a simple TypeScript script can run on the VM.
11+
12+
### Set Up a TypeScript Project
13+
Before testing, we need a project folder with all necessary TypeScript dependencies.
14+
15+
**1. Create project folder**
16+
17+
Create a dedicated folder for your TypeScript project:
18+
19+
```console
20+
mkdir ~/typescript-benchmark
21+
cd ~/typescript-benchmark
22+
```
23+
This ensures all files are organized in one place, separate from system files.
24+
25+
**2. Initialize npm project**
26+
27+
Initialize a Node.js project with default settings:
28+
29+
```console
30+
npm init -y
31+
```
32+
The above command creates a `package.json` file, which manages your project dependencies and scripts.
33+
34+
**3. Install Node.js type definitions**
35+
36+
These definitions allow TypeScript to understand Node.js APIs, enabling type checking and code autocompletion.
37+
38+
```console
39+
npm install --save-dev @types/node
40+
```
41+
42+
You should see output similar to:
43+
```output
44+
{
45+
"name": "typescript-benchmark",
46+
"version": "1.0.0",
47+
"main": "index.js",
48+
"scripts": {
49+
"test": "echo \"Error: no test specified\" && exit 1"
50+
},
51+
"keywords": [],
52+
"author": "",
53+
"license": "ISC",
54+
"description": ""
55+
}
56+
```
57+
58+
### Baseline Testing
59+
After setting up the project, we perform baseline testing to verify that TypeScript is working correctly on the GCP SUSE VM.
60+
61+
**1. Create a Simple TypeScript File**
62+
63+
Create a file named `hello.ts` with the following content:
64+
65+
```typescript
66+
const greet = (name: string): string => {
67+
return `Hello, ${name}!`;
68+
};
69+
70+
console.log(greet("GCP SUSE ARM64"));
71+
```
72+
This simple function demonstrates TypeScript syntax, type annotations, and basic console output.
73+
74+
**2. Compile TypeScript**
75+
76+
The TypeScript compiler (`tsc`) converts `hello.ts` into `hello.js`, which can be executed by Node.js.
77+
78+
```console
79+
tsc hello.ts
80+
```
81+
82+
**3. Run compiled JavaScript**
83+
84+
After compiling the TypeScript file into JavaScript (`hello.js`), you need to execute it using `Node.js`. This step verifies that:
85+
86+
- The TypeScript code was successfully compiled into valid JavaScript.
87+
- The JavaScript code runs correctly in the Node.js runtime on your GCP SUSE VM.
88+
89+
Execute the compiled JavaScript file:
90+
91+
```console
92+
node hello.js
93+
```
94+
95+
You should see output similar to:
96+
```output
97+
Hello, GCP SUSE ARM64
98+
```
99+
This verifies the basic functionality of the TypeScript installation before proceeding to the benchmarking.
Lines changed: 118 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,118 @@
1+
---
2+
title: TypeScript Benchmarking
3+
weight: 6
4+
5+
### FIXED, DO NOT MODIFY
6+
layout: learningpathall
7+
---
8+
9+
10+
## JMH-style Custom Benchmarking
11+
12+
This section demonstrates how to **benchmark TypeScript functions** using a JMH-style approach with Node.js `perf_hooks`. Unlike simple `console.time` timing, this method performs **repeated iterations**, calculates the **average execution time**, and provides more **reliable and stable performance measurements** on your Arm64 SUSE VM.
13+
14+
### Create the Benchmark Script
15+
Create a file named `benchmark_jmh.ts` in your project folder:
16+
17+
```typescript
18+
import { performance } from 'perf_hooks';
19+
20+
// Function to benchmark
21+
const sumArray = (n: number) => {
22+
let sum = 0;
23+
for (let i = 0; i < n; i++) sum += i;
24+
return sum;
25+
};
26+
27+
// Benchmark parameters
28+
const iterations = 10; // Number of repeated runs
29+
const arraySize = 1_000_000; // Size of array
30+
let totalTime = 0;
31+
32+
// JMH-style repeated runs
33+
for (let i = 0; i < iterations; i++) {
34+
const start = performance.now();
35+
sumArray(arraySize);
36+
const end = performance.now();
37+
const timeTaken = end - start;
38+
totalTime += timeTaken;
39+
console.log(`Iteration ${i + 1}: ${timeTaken.toFixed(3)} ms`);
40+
}
41+
42+
// Compute average execution time
43+
const averageTime = totalTime / iterations;
44+
console.log(`\nAverage execution time over ${iterations} iterations: ${averageTime.toFixed(3)} ms`);
45+
```
46+
47+
- **`performance.now()`** → Provides a high-resolution timestamp in milliseconds for precise timing measurements.
48+
- **`sumArray`** → A sample CPU-bound function that sums numbers from 0 to `n`.
49+
- **`iterations`** → Defines how many times the benchmark should run to stabilize results and minimize random variations.
50+
- **`for` loop** → Executes the target function multiple times and records the duration of each run.
51+
- **`totalTime / iterations`** → Calculates the **average execution time** across all runs, similar to how **JMH (Java Microbenchmark Harness)** operates in Java.
52+
53+
This JMH-style benchmarking approach provides **more accurate and repeatable performance metrics** than a single execution, making it ideal for performance testing on Arm-based systems.
54+
55+
### Compile the TypeScript Benchmark
56+
Compile the TypeScript benchmark file into JavaScript:
57+
58+
```console
59+
tsc benchmark_jmh.ts
60+
```
61+
This generates a `benchmark_jmh.js` file that can be executed by Node.js.
62+
63+
### Run the Benchmark
64+
Execute the compiled JavaScript file:
65+
66+
```console
67+
node benchmark_jmh.js
68+
```
69+
You should see an output similar to:
70+
71+
```output
72+
Iteration 1: 2.286 ms
73+
Iteration 2: 0.749 ms
74+
Iteration 3: 1.145 ms
75+
Iteration 4: 0.674 ms
76+
Iteration 5: 0.671 ms
77+
Iteration 6: 0.671 ms
78+
Iteration 7: 0.672 ms
79+
Iteration 8: 0.667 ms
80+
Iteration 9: 0.667 ms
81+
Iteration 10: 0.673 ms
82+
83+
Average execution time over 10 iterations: 0.888 ms
84+
```
85+
86+
### Benchmark Metrics Explained
87+
88+
- **Iteration times** → Each iteration shows the **time taken for a single execution** of the function being benchmarked.
89+
- **Average execution time** → Calculated as the sum of all iteration times divided by the number of iterations. This provides a **stable measure of typical performance**.
90+
- **Why multiple iterations?**
91+
- Single-run timing can be inconsistent due to factors such as CPU scheduling, memory allocation, or caching.
92+
- Repeating the benchmark multiple times and averaging reduces variability and gives **more reliable performance results**, similar to Java’s JMH benchmarking approach.
93+
**Interpretation:**
94+
- The average execution time reflects how efficient the function is under normal conditions.
95+
- Initial iterations may take longer due to **initialization overhead**, which is common in Node.js performance tests.
96+
97+
### Benchmark summary on x86_64
98+
To compare the benchmark results, the following results were collected by running the same benchmark on a `x86 - c4-standard-4` (4 vCPUs, 15 GB Memory) x86_64 VM in GCP, running SUSE:
99+
100+
| Iteration | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Average |
101+
|-----------|-------|-------|-------|-------|-------|-------|-------|-------|-------|-------|---------|
102+
| Time (ms) | 3.217 | 0.631 | 0.632 | 0.611 | 0.612 | 0.614 | 0.614 | 0.611 | 0.606 | 0.532 | 0.868 |
103+
104+
### Benchmark summary on Arm64
105+
Results from the earlier run on the `c4a-standard-4` (4 vCPU, 16 GB memory) Arm64 VM in GCP (SUSE):
106+
107+
| Iteration | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Average |
108+
|-----------|-------|-------|-------|-------|-------|-------|-------|-------|-------|-------|---------|
109+
| Time (ms) | 2.286 | 0.749 | 1.145 | 0.674 | 0.671 | 0.671 | 0.672 | 0.667 | 0.667 | 0.673 | 0.888 |
110+
111+
### TypeScript performance benchmarking comparison on Arm64 and x86_64
112+
113+
When you compare the benchmarking results, you will notice that on the Google Axion C4A Arm-based instances:
114+
115+
- The average execution time on Arm64 (~0.888 ms) shows that CPU-bound TypeScript operations run efficiently on Arm-based VMs.
116+
- Initial iterations may show slightly higher times due to runtime warm-up and optimization overhead, which is common across architectures.
117+
- Arm64 demonstrates stable iteration times after the first run, indicating consistent performance for repeated workloads.
118+
- Compared to typical x86_64 VMs, Arm64 performance is comparable for lightweight TypeScript computations, with potential advantages in power efficiency and cost for cloud deployments.
261 KB
Loading
Lines changed: 60 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,60 @@
1+
---
2+
title: Install TypeScript
3+
weight: 4
4+
5+
### FIXED, DO NOT MODIFY
6+
layout: learningpathall
7+
---
8+
9+
## Install TypeScript on GCP VM
10+
This page guides you through installing **TypeScript** and its prerequisites on a **GCP SUSE Arm64 VM**. We will install Node.js, npm, TypeScript, and ts-node, and verify that everything works correctly.
11+
12+
### Update SUSE System
13+
Before installing new packages, refresh the repositories and update existing packages:
14+
15+
```console
16+
sudo zypper refresh
17+
sudo zypper update -y
18+
```
19+
This ensures that your VM has the latest package information and security updates.
20+
21+
### Install Node.js and npm
22+
Node.js is required to run TypeScript scripts, and npm is the Node.js package manager:
23+
24+
```console
25+
sudo zypper install -y nodejs npm
26+
```
27+
The above command installs Node.js runtime and npm on your GCP SUSE VM.
28+
29+
### Install TypeScript globally
30+
TypeScript (`tsc`) compiles `.ts` files to JavaScript, and ts-node allows you to run TypeScript directly without compiling:
31+
32+
```console
33+
sudo npm install -g typescript ts-node
34+
```
35+
- Installing globally (`-g`) makes `tsc` and `ts-node` available in any directory on your VM.
36+
37+
### Verify installations
38+
Check that Node.js, npm, TypeScript, and ts-node are installed correctly:
39+
40+
```console
41+
node -v
42+
npm -v
43+
tsc -v
44+
ts-node -v
45+
```
46+
47+
**Output:**
48+
49+
```output
50+
>node -v
51+
v18.20.5
52+
>npm -v
53+
10.8.2
54+
>tsc -v
55+
Version 5.9.3
56+
> ts-node -v
57+
v10.9.2
58+
```
59+
60+
These version outputs confirm that the Node.js and TypeScript are installed correctly and are ready for development or benchmarking.

0 commit comments

Comments
 (0)